It’s so true!
I can’t resist showing off my concept art. 40x30 Knight Lore, anyone?
Simon
Yeah I completely agree with fruitmaze. I don’t like the whole open source bit… my engine is proprietary and as a result I’ll have to obfuscate the code before putting the applet up. But, I guess I could post some snippets to prove I’m abiding to the EGA rule if it’s so important. Worst case scenario, someone could write a tool that processes a screenshot of everyone’s game and checks for EGA colors, but that seems a bit extreme :P.
Also, regarding sound, I think it’s pretty common sense to use sounds that fit the style. And a while back when browsing this forum I stumbled upon this app called “SoundGen” made by someone on this forum (I don’t remember who it was, sorry) but here’s the link: http://code.google.com/p/rugl/source/browse/SoundGen/
Ok, in the interest of avoiding confusion and people worrying about having to open source anything I’ll drop the requirement and we’ll just rely on the honour system. But I would encourage people to use one of the open frameworks that are sure to emerge as it will be much easier to get all the entries on a single screen ensuring they all play nice.
Can we have Journal threads like in the JGO Comp?
Of course, we have a sub-forum now and I would strongly encourage it.
In regards to sound. I was looking for ways to program using the PC speaker, and came across a class that mimics the PC speaker with the sound card:
Or rather it generates tones at runtime, so no sound resources are required.
example applet: http://users.on.net/~bobjob/test_tone.html
source: http://users.on.net/~bobjob/tone_source.zip
simple to use you just make static call to the Tone class as follows:
Tone.sound(int tone,int time,double volume);
edit: added a method to queue sound, for music and such:
Tone.soundQueue(int tone,int time,double volume);
I don’t know why but my sound on Java is completely broken (I’m using Ubuntu). I really wish I could try that.
A simple rule to prevent cheating could be that if anyone can produce a (reproducible) screenshot of a game that contains more than 16 colors or any non-EGA color, that game gets disqualified. Also, a screenshot containing more than 40x30 or 30x40 pixels would also lead to disqualification.
But reproducible, I mean that you need to provide instructions on how you got that screenshot so other people can verify it.
I’d still want to open source my framework, but this way you don’t force everyone else to do it while still keeping it fairly easy to distribute the verification and possibly even allowing automated tools to do it.
So as long as it fits on a 40x30 screen we are good (with EGA graphics). This might be great for a first time game making experience.
Count me in, I’ve always wanted to make a tiny Zelda remake.
So are these the colours that we may use in the game:
Yep, and only 16 of those at a time.
I’m definitely interested; as soon as I have a game in mind, I’ll get started.
Proposed end date is during July?
[quote]Proposed end date is during July?
[/quote]
End of August, putting it exactly 6 months apart from Java4k.
wow, how the hell did you pull that off? 
awesome stuff
Paint.net and patience. It’s actually playable, but I wrote a framebuffer -> animated gif converter thing that spat out that thing 
So far I’ve mocked up top-down, 2D platformer and 3rd person not-quite isometric, which all look possible. Getting a good look for 1st person 3D has so far eluded me. The coarse resolution and 16 colours isn’t giving enough scope to antialias to get smooth camera movement. More thought required.
On the framework front, I’ve created a program to generate a palette based png with an indexed palette containing the 64 EGA colours. It’s quite easy to create a BufferedImage with a bespoke ColorModel to do this. All drawing on the Buffered Image is forced into the EGA colour set, although this is probably quite a slow operation.
Creating a BufferedImage with a 16 colour indexed palette to mimic the screen is proving more of a problem. I can’t see how to update the colours in the palette once the BufferedImage is created. It appears I need to create a new BufferedImage, which will be a bit painful on garbage collection. Also I suspect drawing on the image may be slow due to the need to convert pixels from one ColorModel to another.
As an alternative, maybe I should used ARGB BufferedImages throughout, grab the DataBuffer and write low level routines to manipulate it. For instance a Validate method to force all colours into the EGA 64 colours. Or maybe go the whole way and write all the line drawing, image and font routines. This is more work, but should go reasonably fast. One idea is to create an EGAImage class based on BufferedImage. getGraphics() returrns an all new GraphicsEGA class, which may (or may not) extend Graphics. This will have additional methods to handle palette control.
Maybe go for an EGAImage class based on a 64 colour EGA palette BufferedImage, which returns a GraphicsEGA class, based on Graphics, which overrides SetColor, to enforce selection of a colour within the 16 colours of the current palette. Then we can use all the existing drawing primitives from Graphics. There is still a problem with drawImage, as it won’t be forced to convert to the 16 colour palette, but will allow the full 64 colour EGA palette.
Maybe a GraphicsEGA class is more trouble than its worth and I should just write a Validate method on EGAImage, which checks that there are no more than 16 colours in the Image and that they all lie in the 64 colour EGA palette. If they don’t, then generate an error. This means ensuring compliance with the EGA colour scheme needs to be built into the code as a whole, rather than using a class to represent the screen to fix everything.
Overall, I think using indexed palettes will be fast enough given the small screen size. Managing the 16 colour palette elegantly is currently eluding me. Any suggestions. Got to go to work now.
I’m going to use a simple int[] for a virtual screen, and an int[] palette, then assemble a bufferedImage like this:
for (int i=0; i<40*30; i++) bufferedImageRaster[i]=palette[virtualScreenBuffer[i]];
I won’t be using Graphics at all, but rather will write my own rendering functions.
I’m with Markus on this one - you’ll want fast per-pixel access and manipulation, so storing it in a handy int[] or similar is going to be much easier. In terms of rendering functions most of those provided from Graphics2D are going to be useless anyway due to the resolution (eg. rotation) or colour depth (anti-aliasing).
I suspect that all you’d need in EgaGraphics2D would be drawPixel(), drawLine(), drawCircle() and drawText(), all of which are pretty simple to write, and you’d get the advantage of being able to write EGA palette-aware versions. The resolution is so small that it’ll be plenty fast enough doing everything CPU side.
Ah that gives me flashbacks It is almost worth entering just for that fact You used a similar technique with left 4k dead? But mouse ctrl seems just wrong on many levels for this compo, but left 4 tiny dead? 
Haha, great idea