Alter Ego

Use this forum to share and discuss Uzebox games and demos.
User avatar
Jubatian
Posts: 1563
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Alter Ego

Post by Jubatian »

D3thAdd3r wrote: Tue Jan 30, 2018 3:28 amThere is an attract mode, where if you give no input at the title screen, it will play a solution to a random level. I had to keep these very short, as sprite blits crash into them otherwise. Primarily for an Uzebox sitting at a faire, expo, or electronics meet, to catch some attention. AE is not the best fit for JAMMA, but for that too I guess.
OK, now I see that!

I see the memory activity related to playing the demo, it goes on at the upper end of the 0x0D00 bank, which seems to be the end of the RAM tiles. What looks odd to me is that there is a write activity on every screen change to this upper region (0x0C00 and 0x0D00 banks), even when swithing back to the Title screen, but there it is left unused then (only written).

It seems like you are still only accessing the SD card during transitions between screens (the demo data seems to be fully preloaded and then played from those RAM tiles). During this (at least with some care to avoid the sprite system doing stuff on a black screen where it is invisible anyway) you should be able to have the RAM tiles free, which should give enough space to load stuff.

You can use the SetSpriteVisibility() function, which is somewhat misnamed as in the reality (as it is even described there) it turns off sprite processing. So on a blank screen using this you can ensure that all your RAM tiles are left alone even without doing anything to make sure the screen itself is clear (since it is black by fading), allowing to use them to prepare for a level. (There is also a new SPRITE_OFF flag for toggling individual sprites, so you can also turn them off using this flag to free up the RAM tiles while maintaining a "clean'" VRAM).
User avatar
D3thAdd3r
Posts: 3222
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Alter Ego

Post by D3thAdd3r »

Ok perhaps I misunderstood the requirements then. I can trash the 512 byte buffer at some point, and set it up again when it is needed again, without ill effect. If that is so, then the level vram is loaded with intact 512 buffer at the beginning of ram tiles (because enemies are not drawn yet). Then I can trash it with sprites and repeat process when there is a level change. Then it can probably work, and speed should be ok.

On animations parts, pretty sure I must use sdSimple style streaming. There is never at any moment 512 contiguous bytes free during that. So if that part could be unified in with the bootloader API, it seems a one size fits all. At just 1K, flash seems negligible, even if standalone sdSimple were a bit smaller (which I don't know if it is).

I have an in progress level editor now, but it doesn't yet save. I was considering to roll my own copying PFFs process (and I think nicksen782 already did such a thing), where as before the only successful writes I have done were with PFF directly;not an option now since I am not going to have a separate "historical" PFF version.
User avatar
Jubatian
Posts: 1563
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Alter Ego

Post by Jubatian »

D3thAdd3r wrote: Tue Jan 30, 2018 6:52 pm Ok perhaps I misunderstood the requirements then. I can trash the 512 byte buffer at some point, and set it up again when it is needed again, without ill effect. ...
Yes! That's why I linked the guide when I mentioned it, in the "The 512 byte sector buffer" section I describe what you can do with it. Point and shoot, you can repoint it any time between two calls. The state is stored in the SD data structure, the sector buffer is just a sector buffer.

Later I will create the streaming library unless CunningFellow takes the job (please, no upper-case "S" extension then for that, as the kernel's convention is using lowercase, enforcing the use of C preprocessor directives by parameters in the Makefile), before that, I will likely add a sector write function to complete base support.

(General coding conventions in the kernel are a little screwed up. I forgot when creating the bootloader API that the kernel functions are CamelCase() without underscores, I am very much accustomed to underscores, and forgot. sdBase has a problem in this regard: it uses lowerCamelCase() for functions which doesn't seem to be used anywhere else. It seems like the kernel is most often CamelCase() or occasionally all_lower_case() for functions. The file name apart from the extension however is lowerCamelCase which is consistent with the kernel. So a streaming library should probably have a filename like "sdStream.s", and functions using CamelCase() naming, or possibly following what I ended up introducing with the bootloader API as it would build on top of it. It's silly, when doing the SPI RAM library I was aware of having to use CamelCase(), but here possibly because the bootloader came first, I missed it).
User avatar
Kilo
Posts: 330
Joined: Wed Dec 19, 2012 3:43 pm
Location: AC, Germany

Re: Alter Ego

Post by Kilo »

Greeeeeeat game! Awesome!

We need more games like that and Toorum's Quest!
Keep going 😊
The last digit of Pi is 7! I calculated this, as I counted to infinity yesterday!
User avatar
D3thAdd3r
Posts: 3222
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Alter Ego

Post by D3thAdd3r »

Thank you, I appreciate that :) I still remember fondly digging around NES homebrew by Shiru and realizing this game which would work perfectly for the state of Uzebox at that time(SD usage just coming into vogue).

I had some progress quite a while back at converting AE to sdSimple, and that change leaves a lot of extra resources for a level editor like TQ. The other idea is to use Jubatian's bootloader. I did not finish it, and I don't even remember which machine the latest version is on(this is an on going problem for me!). I want to do Alter Ego 2 at some point, but converting the levels manually was too time consuming plus it really did need new graphics and music to match Alter Ego 2 on the ZX Spectrum.

Right now, besides insane work hours, I am very tied up a house which is/was a lake cabin from the 1950's. Ripped it down to the studs and beams to frame out open lake views(sacrificed a bedroom, but I have no kids so oh well!), all new wiring, insulation, vapor barrier, sheetrock, flooring, plumbing, heating...it was a hyper aggressive move. I knew there would be an enormous "sweat/blood/tears cost" here, but I love the location. I am getting past the worst, well maybe, but far from doing "before and after" pictures :lol: When I am to the painting stages, I can start to transition back to Uzebox maybe in some months, which I really look forward to.
User avatar
Kilo
Posts: 330
Joined: Wed Dec 19, 2012 3:43 pm
Location: AC, Germany

Re: Alter Ego

Post by Kilo »

A house is no excuse...so please... Uzebox is more important than a house 🙄😂😂
No problem... take your time!

You are right. The SD usage is coming up. Better games are possible. Great!

It is very awesome to see the different between games with only one small title screen or games like AE and TQ. Really great retro gaming feeling.

I hope there will be more stuff in future. 😉
The last digit of Pi is 7! I calculated this, as I counted to infinity yesterday!
Post Reply