Sorry for starting a new thread — I thought that as I want to make sure everyone who might be interested would notice this it was not a suitable candidate for adding into the bottom of the old thread where it would be only a post edit.

So: the RetroHack competition starts now, with the release of version 1.0 of the RetroHack simulation library.

The rules aren't exactly worded yet, but here is the general timbre:

Submissions are to be made by midnight, GMT, on Sunday 18th of November. They can either be posted to a thread that will be deliberately created on Allegro.cc or emailed directly to me.

Your project, once unarchived (i.e. in a state from which the source code could be built and then executed, including all data files in whatever format the executable will expect them), must occupy no more than 512 kB of disk space. The size of the source code of any libraries that the project uses other than the RetroHack library and any libraries that you would reasonably expect to be supplied with a compiler will be included in this size count.

The entries will be bundled together and released as a source bundle and as executables for both OS X and Windows. Judging will be performed by a popular vote. Categories and marking criteria will be created, the number of which will depend on the interest the competition attracts. They will seek to reward both artistic and technical achievements.

Fixes may be made to the RetroHack library over the course of the competition. In that case each new release of the library will be given a new version number. Entries may use any of the released versions of the library, but a reason must be given if they are found not work with the version of the library that is current at the end of the competition. It is not the entrants responsibility to ensure that they keep up to date with any mid-competition library updates.

Anyway, here it is: http://members.allegro.cc/ThomasHarte/RetroHack/LibRetroHack.zip.
The documentation is here and the AY datasheet is here.

Exciting. The retro feeling of Tetrominoes was fun. I especially liked the Neo Geo-esque beginning. If I make a game I may have to copy that into mine.

I just fear that a month is too long for me to stay interested.

Yeah.... I was reading the Wikipedia page for CGA to get some motivation, and it dawned on me that I would have to make a game that was actually FUN to play, having no graphics to rely on in place of entertainment value.

I think that coming up with a fun idea would take me the most time. I'm currently thinking.

Are there any other rules, regarding, say... disk usage by the program or anything else that might be difficult to arrange on a "genuine" system?

Wohoo . I'm looking forward to this.

And as Harry Carey says, now to come up with a fun idea over the next few weeks...

I suspect there is an error in the keyboard table: there are two RIGHT SHIFTs (line 9, bit 6 and line 7, bit 2) I think one of these should be RIGHT CTRL, most likely the 9,6 combo.
Also there isn't a built-in character set as far as I can see so these will have to be done with sprites, am I right? If so, is there a limit to the number of sprites?

I just compiled the example programs with Linux and I have to say that the sound stutters. It ran okay with the Windows examples, though.

Both fixed!

Any chance of trying the new retrohack.c file attached to this post? It substantially increases the frequency of the get_audio_stream_buffer checks. If it fixes the problem I'll make it version 1.1 of the library.

I'm going to try and put together a version with a dynamic buffer size, to fix this problem without introducing undue latency on the other platforms. I hope you'll be able to help test it?

In the mean time, RetroHack now has a hastily constructed webpage: http://members.allegro.cc/ThomasHarte/RetroHack.

EDIT: further to the Linux sound issue, I'd be grateful if you give the attached version of retrohack.c a go. It attempts to automatically pick the buffer size at runtime. On my machine it usually goes for 512 or 1024, which is good because I can hear the sound breaking up if I manually force lower numbers.

Oh, I see what I did! It can't cope with buffer sizes over 4096, yet tries to select them anyway, and if it ends up with one then it sticks with it forever.

So, hopefully both those two things fixed, try the attached?

EDIT:

The full screen logic is "try for 320x240, if Allegro can't set that then use 640x480". So really this is an Allegro/X-Windows issue. But I'll think about it.

I've never been a big fan of those effects (see also: the way I've never implemented them in any of my emulators, you'll probably also need to see ElectrEm to see one of my emulators, but the Linux port is long broken so you probably can't anyway), but I'll look into it. If I implement anything it'll be a classic computer to TV thing like the chrominance being slightly out of sync with the luminance. Which isn't that hard to achieve with the way I have the palette set up...

EDIT2: Oh, baring in mind those comments I think now is a good time to further discuss the rules re: new library releases mid-competition. The burden is primarily on me to (a) fix bugs; and (b) not break backwards compatibility. The "a reason must be given if they are found not work with the version of the library that is current at the end of the competition" is present so that if I have made some sort of idiotic mistake that means the entire point of the competition can be avoided (as per an early version of the code, which credited you with extra cycles if you blitted stuff mirrored across the y-axis) and an entrant deliberately exploits that to gain an unfair advantage then there is a mechanism for removing that advantage.

Thomas, is the colour palette set? If so, what are the colours? Or can we use Allegro to change it?

Heh, I missed that one . Cheers.

Ok, the sound works fine now.