archive.worldofdragon.org

Taking inspiration from Stew, a little dev diary.

http://www.6809.org.uk/dev/dunjunz/

It's got videos in it and everything. No release yet, hoping to have something to show in Cambridge perhaps.

Cool!

Looking forward to see it in motion in Cambridge!

May I ask?... I saw you tried the blue-red lines to create the purple background. Of course that only works on PAL machines, but my question would be if you emulate that on XRoar same as NTSC artifacting?

Keep up the good work!

Oh, very interesting. I'm a big fan of this type of game, as if that wasn't obvious.

These types of games are a struggle with only 32K of memory, so Glove had everything (except projectiles) as "blocks". The blocks each had 4 bytes of data associated with them, including a "half-bit" for X and Y, as well as the sprite frame, AI index and other things.

This meant that the whole level could be expressed as 32*32 (1024) bytes (this basically constituted the map and the list of objects), along with the data structures for each of the possible 256 objects: 256*4 (1024) bytes. There were eight projectiles (sprites, which were XORed on top) they had slightly bigger data structures, so that was another 64-128 bytes (I think).

This was very size-efficient, but it meant that the movement and collision routines were complicated and somewhat frustrating to get right! It does mean that you don't have to compare against a large list of objects, though.

You could do something similar for Dunjunz, but the monsters seem to like walking over things (like trapdoors and food). Maybe have two layers (as it seems to already?) or treat the monsters as sprites on top of the map. Or treat the objects that the monsters can walk over as sprites?

robcfg wrote: May I ask?... I saw you tried the blue-red lines to create the purple background. Of course that only works on PAL machines, but my question would be if you emulate that on XRoar same as NTSC artifacting?

Nah, XRoar doesn't do anything PAL yet, nor does it try to handle any sort of
colour bleed between lines. One day! I've generally figured that PAL won't be
coming until I properly bolt in some shaders.

..ciaran

jmk wrote:Oh, very interesting. I'm a big fan of this type of game, as if that wasn't obvious.

There were one or two subtle clues

Quite helpful for me is I'm only converting something another 8-bit micro has already done, so a lot of the visual artifacts (like flickering items, etc.) I can consider part of the aesthetic. Kinda important sometimes too - it's good to see if there's an energy drainer, key and dead body all on the same square, and without lots of slow masking and draw ordering that would be tricky.

I've learnt a lot about what the beeb version must be doing under the hood just by watching it closely.

My sprite data structures are relatively huge! Players take 32 bytes each at the moment - monsters somewhat less... But that's because I'm caching lots of things like their viewport offset in bytes, which sprite to be drawing for them, which *tile* to draw to undraw them, etc.

You could do something similar for Dunjunz, but the monsters seem to like walking over things (like trapdoors and food). Maybe have two layers (as it seems to already?) or treat the monsters as sprites on top of the map. Or treat the objects that the monsters can walk over as sprites?

Yeah they trample over everything. No respect. At the moment I'm drawing all (visible) items all the time, but I hope to cut that down only to objects something's actually stood on. And energy drainers - if you watch, you'll see I'm faking the "flashing" colours from a BBC Micro - and obviously to do that on our platform that means constant redraws. Oh yes, and keys. As I say, you want to see where they are...

..ciaran

Love it Ciaran! Your game looks great and the blog is great read too. Very inspirational!

It really does make me feel as if I've been transported back to the computer room at school. May the lunch break never end...

This is exciting news Ciaran.

Looking forward to getting home this evening and taking a proper look at your blog and game.

sixxie wrote:I've learnt a lot about what the beeb version must be doing under the hood just by watching it closely.

My sprite data structures are relatively huge! Players take 32 bytes each at the moment - monsters somewhat less... But that's because I'm caching lots of things like their viewport offset in bytes, which sprite to be drawing for them, which *tile* to draw to undraw them, etc.

There is a small GBA demo of Dunjunz: GbaDev.org
It includes some C++ source code. Judging by the text files, it seems to be derived from experimentation rather than reverse engineering. It is rather unfinished, so I don't know if it'll be much help.

I've been playing the beeb version and it is quite a tough game! Very easy to get caught between monsters and lose a lot of energy.

It took me quite some time to figure out the keyboard controls. One difficulty will be finding a set of keyboard/joystick combinations that manages to work without any matrix errors!

Oh absolutely - picking a set of keys that weren't masked out by the firebuttons was pretty important. I still need to test whether ghosting will cause problems with the set I've chosen. That'll need me to borrow a second pair of hands and get real hardware down from the loft...

Thanks for the encouraging words, all

Love the blog and wip videos!

It's great we now have several new games in development, (that we know of).