Thanks! Thought them being fairly clear as on the map they match the symbols of the corresponding statuses. They are Energy (Collected at 4:03), Fire (Collected at 6:58) and Life (Collected at 7:48). Make sure to grab these as they don't just add extra of each stat, but also boost the regeneration of them. There is a further set of them on the further levels to max out every one of them. Apart from these, there are also the hourglasses for extra time, on later levels you might need to look out for them in order to make it to the end!
Flight of a Dragon
Re: Flight of a Dragon
Re: Flight of a Dragon
I thought that the last time I tried to build FOAD it didn't build but maybe I just saw the packrom error or something and didn't notice that it did actually did build OK. The .hex file builds fine for me under Debian, even without having packrom in the correct path to build the .uze but thats easily fixed of course.
FOAD is one of the most impressive Uzebox games but I'm not a fan of the music and sfx. What I propose we do is we sort out the Uzebox music production toolchain first then I can ask my FB friend Koichi Namiki if he's got any tracks he might wish to let us use for FOAD? Then DA and myself, or just me if DA isn't up for this, can convert KN's tracks for the Uzebox, if KN doesn't want to or doesn't have time to do it himself?
That would be about as close as we'll get to SEGA doing a Uzebox game, for the moment at least...
Does that sound like fun to anyone else?
FOAD is one of the most impressive Uzebox games but I'm not a fan of the music and sfx. What I propose we do is we sort out the Uzebox music production toolchain first then I can ask my FB friend Koichi Namiki if he's got any tracks he might wish to let us use for FOAD? Then DA and myself, or just me if DA isn't up for this, can convert KN's tracks for the Uzebox, if KN doesn't want to or doesn't have time to do it himself?
That would be about as close as we'll get to SEGA doing a Uzebox game, for the moment at least...
Does that sound like fun to anyone else?
Re: Flight of a Dragon
Or maybe I can try asking Rob nicely?
Is there enough memory left, or can you squeeze out some space, for adding some better music Jubatian? Maybe there could be an SD only version with better/more music?
Is there enough memory left, or can you squeeze out some space, for adding some better music Jubatian? Maybe there could be an SD only version with better/more music?
Re: Flight of a Dragon
This game has its own sound engine, there is nothing left from the Uzebox kernel's original music player. Much smaller (music.s, and an assembler patch processor in the kernel totalling ~1Kbyte as compared to ~4Kbytes of the original kernel's) , and geared towards heavy reuse of sequences - where you hear something repeating, it is reading the same byte sequences to produce it. The in-game theme is some 300 bytes only (!), found on the bottom of res.s. This was created entirely manually after putting the theme together (more or less with the intended instruments) in a tracker.
The game has no RAM left, literally every byte of the Uzebox's RAM is used for something. Even the stack's area is reused - within the video mode, the game resets after every video frame (!).
There is no ROM left either, at least practically - the little what's left is pretty much sufficient just to accommodate for compiler version differences.
Putting SD support even using the bootloader library in it is impossible - there is no place to put an SD buffer at, or any state to handle the card, plus the game can't handle easily something spilling out of the VBlank (as it resets every frame) - the design is heavily tailored for this operation. Resetting within an SD transfer however would make a mess.
The game theme, true it is nowhere near as good as I wished it to be (and the music engine certainly could do much better in the same ~300 bytes footprint as well), that's just a skill I don't have. However it roughly gives the idea I wanted for this game, a slow, mysterious cave theme (where a lot of the game takes place), with bursts of energy, scattered around, kind of rising up.
Might later try to redo it (I guess nobody would be too keen to manually create and hand-optimize music tracks for this thing), maybe seeing whether a second theme could somehow be also crammed in for surface levels.
The game has no RAM left, literally every byte of the Uzebox's RAM is used for something. Even the stack's area is reused - within the video mode, the game resets after every video frame (!).
There is no ROM left either, at least practically - the little what's left is pretty much sufficient just to accommodate for compiler version differences.
Putting SD support even using the bootloader library in it is impossible - there is no place to put an SD buffer at, or any state to handle the card, plus the game can't handle easily something spilling out of the VBlank (as it resets every frame) - the design is heavily tailored for this operation. Resetting within an SD transfer however would make a mess.
The game theme, true it is nowhere near as good as I wished it to be (and the music engine certainly could do much better in the same ~300 bytes footprint as well), that's just a skill I don't have. However it roughly gives the idea I wanted for this game, a slow, mysterious cave theme (where a lot of the game takes place), with bursts of energy, scattered around, kind of rising up.
Might later try to redo it (I guess nobody would be too keen to manually create and hand-optimize music tracks for this thing), maybe seeing whether a second theme could somehow be also crammed in for surface levels.
Re: Flight of a Dragon
There are some very extreme optimizations in this game to fit the content it has - I remember seeing discussions here on Mode 74, whether it has any megasprite support since Flight of a Dragon clearly does large sprites - however those are also something very different.
For every FoaD "megasprite" any 8x8 sprite can be placed anywhere. You can see the source for (again manually typed up into res.s) sprite combinations in assets/dragon_sprites , that contains a Gimp .xcf file for each dragon frame, with the sprite tiles as layers, the layer name giving the sprite IDs.
The sprites where the dragon is looking up (you can do that holding down Up) are notably just derivatives of other sprites, replacing the dragon's head only to the appropriate tiles.
Nowadays I would likely try to write Python tools for these, might eventually do so if I decide to make another game reusing this game engine (the Outpost in the Dragon's Maw has Python tools, and generates its assets directly from the sources, so I can edit a .png file, hit "make", and it is in the game right away). Some ludicrous amount of manual effort went into this game overall
For every FoaD "megasprite" any 8x8 sprite can be placed anywhere. You can see the source for (again manually typed up into res.s) sprite combinations in assets/dragon_sprites , that contains a Gimp .xcf file for each dragon frame, with the sprite tiles as layers, the layer name giving the sprite IDs.
The sprites where the dragon is looking up (you can do that holding down Up) are notably just derivatives of other sprites, replacing the dragon's head only to the appropriate tiles.
Nowadays I would likely try to write Python tools for these, might eventually do so if I decide to make another game reusing this game engine (the Outpost in the Dragon's Maw has Python tools, and generates its assets directly from the sources, so I can edit a .png file, hit "make", and it is in the game right away). Some ludicrous amount of manual effort went into this game overall
Re: Flight of a Dragon
!!!
Ah well! I'm glad I asked as your explantion why only served to make the game more impressive than it already was.Jubatian wrote: ↑Sun Jan 07, 2024 6:25 pm Putting SD support even using the bootloader library in it is impossible - there is no place to put an SD buffer at, or any state to handle the card, plus the game can't handle easily something spilling out of the VBlank (as it resets every frame) - the design is heavily tailored for this operation. Resetting within an SD transfer however would make a mess.
Re: Flight of a Dragon
Eh, I enjoy the story of how it's made and its challenges as much as the game itself! The reset on every frame part blows my mind! Another clever trick for the uzebox toolkit.
Re: Flight of a Dragon
Thank you! The reset on frame is an interesting one indeed - it does two things.
One is more RAM by eliminating the need for retaining the stack while the video frame is ran.
The other is consistent timing, which of course took some careful design. The display generation is purposely made so that it doesn't artifact if reset hits it (this is mostly in Mode 74's design), so you would only have a few things missing, nothing worse, if the VBlank wasn't enough.
On my new game (struggling to get it finished :p ) I didn't use this, there RAM is plentiful, and it also has hardly any graphic rendering to do (the power of HSync sprites).
One is more RAM by eliminating the need for retaining the stack while the video frame is ran.
The other is consistent timing, which of course took some careful design. The display generation is purposely made so that it doesn't artifact if reset hits it (this is mostly in Mode 74's design), so you would only have a few things missing, nothing worse, if the VBlank wasn't enough.
On my new game (struggling to get it finished :p ) I didn't use this, there RAM is plentiful, and it also has hardly any graphic rendering to do (the power of HSync sprites).