Weber's Rants (tutorials)

[D3thAdd3r]

Just wanted to make a quick note, Sokoban World source code is released albeit very messy code. This and my other stuff should eventually make it to here. Recently I've had no time to work on Uzebox stuff and likely wont for another month, but hopefully I'll be able to come back strong and finish Lolo etc up. Anyone who's curious on that project, well the big hang up is space and constantly reorganizing/cutting/recoding things to be smaller. Sadly I don't think bootloader will be possible no matter what I do. Anyways since this is sort of my random junk thread, and we haven't had many teasers as of late, I thought I'd stir it up with this still very early prototype(not worthy of it's own thread yet). Kind of shows off how well Uzebox can handle sprite intensive games with a little creativity applied. I think the game is realistic to pull off on Uzebox, with the most important gameplay aspects intact.

[hpglow]

That plays pretty well, I'm suppried to see no flickering or anything. Makes me miss playing 5 way Bomberman on the TG-16.

[uze6666]

Awesome!! Lot's of progress since your last prototype...and I can see you're getting pretty good at sound & music! A future Uzebox classic!

-Uze

[digitalicarus]

So, I've been trying sprite flipping with a very limited scenario. I'm trying to just display one sprite on even frames and another on odd. However, when I do this I can only get the emulator to show both if I use interlaced mode. I notice on your bomberman game you are able to get many sprites on the screen without noticeable flicker but I didn't have to use interlaced mode. What am I doing wrong?

Code: Select all

        MapSprite(0,map_normal_baby);
        MapSprite(1,map_evil_baby);

        while(1) {
                if (GetVsyncFlag()) {
                        ClearVsyncFlag();

                        if(ticks % 2) { // only this one shows up if uzem not in interlaced mode (-i)
                          MoveSprite(0, 16, 16, 1, 1);
                          MoveSprite(1, SCREEN_TILES_H*8, 16, 1, 1);
                        } else { // this is totally ignored in progressive mode uzem (default no switches)
                          MoveSprite(1, 32, 16, 1, 1);
                          MoveSprite(0, SCREEN_TILES_H*8, 16, 1, 1);
                        }
                        ticks++;
                }
        }

[uze6666]

In bomberman the sprites movements are restricted to a single axis at a time and they also align flush on tile boundaries (8x8 pixels). So to move those 4 guys made of 2x2 sprites, you will need a most 6 ramtiles when moving. 3x2 horizontally or 2x3 vertically. If that doesn't make a lot of sense, check these wiki pages: http://uzebox.org/wiki/index.php?title= ... Techniques and http://uzebox.org/wiki/index.php?title=Hello_World. They explain this concept pretty well.

-Uze

[digitalicarus]

Wow! Quick response!

That's a good reminder about alignment, but specifically I'm referring to blinking the sprites. If I do a simple case where I alternate just two sprites from frame to frame then I have to put the emulator in interlaced mode and then there's scanlines. I referred to bomberman because I'm sure there's some cycling going on as I play it but it's not noticeable (even without interlaced mode).

In my simple case of flipping two sprites frame by frame I have to bump up the frame "flicker" to 5 frames to get both sprites to display without interlacing enabled. Meaning in my code snip it would be ticks % 5 with a ticks = 1 in the if block. Otherwise I never really get to see the other sprite being put into view in the else block.

My guess is that the emulator is skipping odd frames and interpolating the extra lines when it's not running interlaced. I will test again in windows. Right now I'm running in a linux vm which could be dropping frames, but it seems to render all of my frames in interlaced mode so I suspected the emulator.

[D3thAdd3r]

The mega sprites in MegaBomber are all 2x3 so 9 ram tiles when moving horizontal. Like was said the grid alignment is key and on average no scene ends up severely lacking. The rotation system is pretty simplistic, if I recall, but manages to pull off 24 sprites per frame well. I will try to release the source soon, but its nothing too fancy. Really haven't looked at it in months.

[D3thAdd3r]

The following is a huge rant, mostly because I enjoy discussion with others on technical subjects and ideas and am totally wired. As usual, apologies in advance

Great progress has been made on MegaBomber, some of which may not be obvious. Recently I went from hopelessly past the flash budget(much less to fit with the bootloader), to having very near 9k left (sitting at 52,788) AND fit the bootloader!!! I am calling it a Beta at this point, and am interested in feedback regarding gameplay/features/especially any ideas. Don't need bug reports, so much testing...I am aware of all of them I have been coding, cutting, recoding, and testing every variation and configuration of features to get the best overall experience in the final game. Right now the AI is silly, working on fine tuning the weight gates to make them avoid obvious mistakes in their escape path/bomb placement(which they do know better actually...again the weight system) and navigate the level better. For testing, I recommend setting another player spot to MAN in the setup menu so that there is always one other alive and the round doesn't end because of stupid bot suicides. Most focus is on AI right now, and I am confident I can create a reasonable opponent. I have 4 levels roughly half done like this current build, each with it's own special novelty. Will probably be adding back a couple things I took out, and some new features. Crazy I know, but I am still earmarking code space for my Uzenet controller port->serial port->internet tunnel->master server idea. Need to test out 4 player adapter also.

Some interesting methods I've come up with, due to no great personal attribute, other than spending extreme(stupid amounts) of time, thought, and experimentation into this game. And also ignoring the significant other way too much, and hearing about it...repeatedly...Anyway, I think they would be useful to anyone trying a game that will be pushing the Uzebox to the max, so I'll briefly describe them and probably put something in my tutorial sections. MegaBomber could not have been done without this trickery. Currently, with the included level compiled I have almost 9K left!! That includes fitting the bootloader. These are methods I recommend to anyone feeling something can't be done due to space, time, or ram in Mode 3.

*Font compression - 1bpp and decompressed rendering to ram tiles. My font set consists of A-Z + 0-9 and takes 288 bytes for the entire thing, plus some minimal code cost much less than the space savings. Also have the ability to change font color at will for no extra space. Does require some nasty coding, manual reuse of characters you don't need for other ones, shifting, etc. Main thing, have lots of ram tiles and be a micro designing masochist. I am developing a more efficient system that stores characters similar to 11-16 segment alpha-numeric displays, with each character requiring only 16 bits(one for each segment) instead of 64. Something like thishttp://coderseye.com/2006/15segment-display.html

*Pallet Sprites with Compression - Originally the MB demo had 4 different characters, and it looked very nice. Quickly I found it was impossible to finish if I was to waste that much space on sprites. Uze was kind enough to give me the C version of BlitSprite(with flipping) and I created PalletBlitSprite which allows me to use the same character graphics with a different pallet. The speed penalty is small, and it effectively quadrupled the effectiveness of sprite space usage by using one graphic set recolored 4 times. Usually sprites have less than 16 colors, so I was looking for a way to utilize the upper 4 bits(since now each byte does not represent the color, but rather and index into a pallet). Simplest way for me, without major recoding on BlitSprite, I interleaved every other sprite so even sprites use the lower 4 bits of a byte and odd sprites use the upper bits. Made a tool to convert graphics for me and it is fast enough even in the current C version! Huge deal, massive savings, pretty much the silver bullet! I am now considering adding several extra frames/actions for the characters (bomb carrying/throwing/special object hopping into).

*Expense Cutoff system - my goal was to be able to have bot's thinking(absurdly expensive) and up to 16-20 bombs exploding(with longest possible range, also ridiculously expensive), standard logic, and level special logic running, and never crash. Well, testing proved that didn't work that way by itself I implemented a system that logs expense of computations(based on my estimates) before and during several heavy points and in expensive iterations(AI,Bombs exploding, etc), that will WaitVsync(1) if expense is greater than the cutoff value. Since sprite placement is at the end of tick, there is no need to blit ram tiles until the tick is over(so you catch up on time quickly, need to modify the kernel a bit to know when this is happening). Basically the game slows down instead of crashing, I recommend this method makes much greater things possible. Of course you'll notice that I cheat using a VRAM height of 22 instead of the standard 28, this gives me tons of extra time as well as eliminating the need for border graphics and freeing up enough ram for 2 extra ram tiles. At this point, the game really has no need to slow down in any situations I can create easily. If you can get it to crash I would like to know!

*Weighted AI system - wont even get into this yet, since it's playing ability is somewhat embarrassing at the moment...

Anyways, here is the build I'm working on right now. Might be a couple debug things I forgot to turn off, but I really will finish this guys All these space tricks will also save Lolo as it saved MB.

[paul]

288 bytes for an entire font set that can be any colour...how could anyone not want that?! Pac-man wouldn't need a lite version with that trick. These 'tricks' may open up a lot more possibilities for the Uzebox. You see if we had 128k and 56MHz, no one would need these ideas. How dull would that be?

[Harty123]

Hi,

this looks very good... nice work. Can't wait until finishing of this nice game...

-Harty