Adventures Of Lolo

Use this forum to share and discuss Uzebox games and demos.
User avatar
D3thAdd3r
Posts: 3222
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Adventures Of Lolo

Post by D3thAdd3r »

Here's the thread for Adventures of Lolo. Attached is a hex file with the current progress. Check out the wiki I will get a little more info up there as it nears playable status. Big props to Uze for the well done level music, and useful suggestions. Thanks also to Paul for his useful suggestions. Progress IS being made!

Image

To be released: "when it's done" (not in the Duke Nukem ForNever sense)

The current status:
-Most graphics and sound complete.
-Most gameplay in place.

Todo:
-Redo moving enemies to be smart(so that the trickiest levels work like in the originals)
-Fix and finish gameplay elements

http://uzebox.org/wiki/images/a/a9/Oldlolo.hex latest release
Last edited by D3thAdd3r on Wed Mar 24, 2010 10:57 am, edited 7 times in total.
blue_knight
Posts: 48
Joined: Sun Dec 06, 2009 8:08 am

Re: Adventures Of Lolo

Post by blue_knight »

The game is really nice so far. Obviously some things are still being worked on, but what is there is very promising. :)
User avatar
paul
Posts: 457
Joined: Sat May 02, 2009 8:41 am
Location: Brisbane, Australia

Re: Adventures Of Lolo

Post by paul »

Wow, the productivity level around here is crazy...

Nice one, Lee! It really doesn't look very far from complete. Hopefully you have plenty of flash left? If not, you can always remove the level editor code and release it as a separate hex. Btw that title fade in is nice - I'll have to remember that one.

The hero is a funny little guy :D Looking forward to it.
User avatar
D3thAdd3r
Posts: 3222
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Adventures Of Lolo

Post by D3thAdd3r »

I'm doing pretty well on flash ~57k with full graphics load, sprite flipping is where it's at. Editor shouldn't take up too much, no bells/whistles and it reuses the normal engine functions. The question of usefulness comes to mind of course but is overridden by cool factor.
Last edited by D3thAdd3r on Mon Jul 13, 2015 12:05 am, edited 1 time in total.
Reason: LoLo = Lolo
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Adventures Of Lolo

Post by uze6666 »

Awesome! :mrgreen: Just like playing on the NES, a near perfect conversion so far! If you still have a bit of flash left I could convert some shorter songs too, like dying, end of level, etc.

Uze
User avatar
D3thAdd3r
Posts: 3222
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Adventures Of Lolo

Post by D3thAdd3r »

Just wanted to make a small progress update. Got a little work done on it today. Several little things don't work that did in the last version relating to GFX offsets, I'll get it back together again.Mainly I've done a good bit of reorganizing the graphics and optimization but there is still a lot of improvement possible. Cleaned up some old stuff and removed the editor. Fixed Lolo's death to match Lolo 2, try a (Don)Medusa. So I'm sitting at <59k with 25 levels.Main thing with this release is 2 dynamic enemies Leeper and Don Medusa are roughly working plus half assed others you wont see yet. Push start to skip through levels, must move before enemies will. That being said the screen can be full of tile based enemies or animated water without much effect BUT it will take quite a bit to get 3 moving enemies at a time without slowdown or simple level. Level design can help here though lots of fun maps don't have more than 2 if any dynamics. Seems to me that all the speed loss and complication of using vram as the level array may be worthless. I have 28 ram tiles, any object on the screen is always 8 pixel aligned on at least 1 axis. If on both it will be drawn with tiles. Am I mistaken or is the max a 16x16 enemy could take 8 ram tiles under those conditions? If so then I'm running out of time in certain situations, but I haven't used any of my tricks and theres way more function overhead than I need. So I think 3 enemies will be possible with a little flicker. Any I may just cut some ram tiles and have an 11x11 map array, it would be drastically faster/easier and I could implement a good sprite overflow rotation. There is a surprising amount of code in this game, maybe someone will find it interesting after it's all cleaned up. Would be "easy" to turn this into Uzebomber or another simpler grid game. Before next release I'll try to get something more substantial done and some levels might even be playable then. I do believe this concludes today's aimless rant, more to come however.
Attachments
lolo.hex
(161.72 KiB) Downloaded 449 times
User avatar
paul
Posts: 457
Joined: Sat May 02, 2009 8:41 am
Location: Brisbane, Australia

Re: Adventures Of Lolo

Post by paul »

Am I mistaken or is the max a 16x16 enemy could take 8 ram tiles under those conditions?
I think 6, under those conditions, with Lolo taking at most 9. I think at 28 ram tiles you will be squeezing stack space pretty tightly and no doubt the cycles will be high. I would like an option in mode 3 for no ram tiles; I don't think your game needs them, but you still pay for them.

I'm having trouble moving the barriers (I'm not sure how they're supposed to move as I have not played the original). I'm also not sure how powers work as each time I use one I just seem to die. Shooting an enemy when not square can leave gfx artifacts. You might already be aware of these, but I thought I would mention them in case.

Otherwise, it's looking almost done :)
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Adventures Of Lolo

Post by uze6666 »

I would like an option in mode 3 for no ram tiles; I don't think your game needs them, but you still pay for them.
Not sure what you meant here, but to have moving sprites like Lolo, he definitively needs ramtiles. And as you said 6 ramtiles is the max required for single axis movement of 16x16 sprites.

-Uze
User avatar
paul
Posts: 457
Joined: Sat May 02, 2009 8:41 am
Location: Brisbane, Australia

Re: Adventures Of Lolo

Post by paul »

uze6666 wrote:
I would like an option in mode 3 for no ram tiles; I don't think your game needs them, but you still pay for them.
Not sure what you meant here, but to have moving sprites like Lolo, he definitively needs ramtiles. And as you said 6 ramtiles is the max required for single axis movement of 16x16 sprites.

-Uze
Well I thought ram tiles were for overlapping sprites - but I guess you need them for more than that? Maybe that's where the higher res comes in, but I was hoping for closer to mode 2 sprite count by eliminating the sprite overlapping features - or at least to regain cycles by not considering transparency of overlapping sprites (similar to mode 2).

Edit:

So I reread the wiki for vmode 3 and I guess ram tiles are integral to offering sprites at that resolution due to the preprocessing that ram allows (like a mini frame buffer). If you can skip tests for overlapping sprites easily when you know there's no overlaps, I guess I'll stop asking for this "feature" :lol:
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Adventures Of Lolo

Post by uze6666 »

So I reread the wiki for vmode 3 and I guess ram tiles are integral to offering sprites at that resolution due to the preprocessing that ram allows (like a mini frame buffer). If you can skip tests for overlapping sprites easily when you know there's no overlaps, I guess I'll stop asking for this "feature" :lol:
True. You need ramtiles to blit sprites against background tiles and in this respect they indeed act like 8x8 pixels mini frame buffers (I love that analogy :P). However you can't get away with the tests for transparency (in this implementation at least). To help here's how mode 3 works in a nutshell (I should really do a formal doc on this one day :roll: For now, I'll add this to the WIKI):

Mode 3 uses a "restore buffer" in addition to a byte VRAM array. This buffer has as many slots as there is ramtiles. Each slot is composed of a VRAM address (2 bytes) and a tile index (1 byte). At the beginning of each frame (during VSYNC), sprites are processed. For each 8x8 pixels sprite, we compute which VRAM background tile(s) are overlapped (up to 4 tiles can be overlapped, so 4 tests are done). Two cases can then arise:

1) the VRAM tile index is >=RAM_TILES_COUNT which indicates the sprite will overlap a regular flash tile. In this case, we check if we still have unallocated ramtiles. If so, the overlapped flash tile's pixels are copied into the newly allocated ramtile. The new ramtile index in set in VRAM (the previous VRAM value & adress is preserved in the restore buffer). The sprite is blitted against this ramtile (which contains only the flash tile pixels at this point). If no more ramtiles were available, the sprite blitting against this VRAM location is clipped/ignored.

2) the VRAM tile index is < RAM_TILES_COUNT which indicates the sprite will overlap a previously allocated ramtile. The sprite is blitted against this ramtile (which contains the bg flash tile pixels overlaid with perhaps one or more sprites pixels).

When rendering begins, the tile indexes in the restore buffer are updated with the current VRAM values. This is required since the main program may have updated the VRAM between VSYNC and rendering. So for each slot in the restore buffer, we check if the tile index in the matching VRAM location is < RAM_TILES_COUNT. If not we know there has been an update and we store the new VRAM tile index in the restore buffer and write the restore buffer's slot index into that VRAM location.

The main rendering loop then goes through the VRAM tile by tile. Two separate "sub loops" handles flash and ram tiles. When using scrolling there was no cycles left in the flash inner loop to perform X wrapping so we need to "pre-wrap" the current tile row into a "linear" buffer so we don't need any wrapping during rendering. This unfortunately adds overhead to each scanline and reduces the displayable tile from 30 to 28.

Once frame rendering is finished, the VRAM is restored using the "restore buffer" values.

-Uze
Post Reply