Alter Ego

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

Re: Alter Ego

Post by D3thAdd3r »

Thank you, that means a lot :)

You can change the tilesets and the properties(foreground, solid, alter solid, insta-death, etc) of the tiles quite easily(requires recompile) and you can have up to 255 levels and 255 demos for no extra flash cost. Mainly it is just extendable enough so it can do AE2 or similar custom episodes. The new AE2 enemies/mechanics are already working an implemented if the level object is placed. The file format of the SD data file is setup for different episodes with custom titles, screens, levels, demos, etc all in the same actual file with a select menu at the beginning if there is more than 1 episode in the file. Level editor wouldn't be too bad and it pretty much is asking for a sequel. Denis Grachev(original creator) already has those nice AE2 levels asking to be rippedd and he basically said AE2 should get ported too. Hmm, it really should be done.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Alter Ego

Post by D3thAdd3r »

I pulled out my old notes and see I never did find the level data in the rom though I didn't do much corrupting to search for it as that is a rather time consuming process. At least I have a screenshot of the initial state of every level of the ZX Spectrum version(32 total), but don't care to do the "analog loophole" way unless it was the only way. I contacted Denis Grachev and asked if he still had the uncompressed versions of the levels or could describe it's format so I could rip them from the rom. Also AE2 music is really good so hopefully he has that as well, we will see on that. Sounds like tracker music so I might need a favor from Alec if that happens too. Personally I find AE2 to be superior all around to the 1st, but I find it much easier to get resources from the NES which I have intimate knowledge of...not at all the Spectrum(though I treated myself to a lovely Spectrum +2A in original box...wow...those....cassette......load...........times 8-) )

I worked on a quick level editor but I see no way around this fundamental problem of where to put the data. To be useful you need to be able to step in and out of gameplay mode while preserving the WIP level you're building. AE ram is already highly compressed gameplay wise. With Uzem not being able to write to SD it only leaves me with some bizarre EEPROM solution to restore the level to where you left off editing after play testing. Either that or SPI ram but that's not really an option yet either. That is, if I don't just do it manually in a hex editor again since it might still be faster overall :| I'm going to let it stir for a while and see what happens.

PS. I suppose it would be possible to hack a poke/peek stack into Uzem and use that. Even though it wouldn't work on real hardware, there isn't much reason to do such things on it anyway.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Alter Ego

Post by uze6666 »

I worked on a quick level editor but I see no way around this fundamental problem of where to put the data. To be useful you need to be able to step in and out of gameplay mode while preserving the WIP level you're building. AE ram is already highly compressed gameplay wise. With Uzem not being able to write to SD it only leaves me with some bizarre EEPROM solution to restore the level to where you left off editing after play testing. Either that or SPI ram but that's not really an option yet either. That is, if I don't just do it manually in a hex editor again since it might still be faster overall :| I'm going to let it stir for a while and see what happens.
So I guess we have some real case for sd write support in uzem. That and I also wanted it for a tracker I started working on. :)

As soon as the optimizations in uzem slows down and I can refactor the SD code as mentioned in another thread, I'll give a first shot at the SD write support. For sure, It's going to be trickier to implement than just reading.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Alter Ego

Post by D3thAdd3r »

<rant>
I played AE for the first time in long while and I noticed CUzebox does not like Alter Ego's hsync timing for the release rom that is posted. I noticed also that the source I provided(which definitely used to produce a working game when I used AVRStudio years back), does not build a working version against the newest kernel/GCC under Linux. I tracked this down to some CFLAGS in the makefile, but even the custom AETriggerFx doesn't work in the new kernel, as some internal track structure changed since then. In short, the source of AE has been in a terrible state since the beginning, and I believe no one has successfully built a working version with what I provided.

I decided I need to perform some maintenance on this so it at least builds right, but I got a little crazy and just ripped out all the PFF stuff. Now that bothers me a bit since I wont have a working "classic" version based on PFF when I am done, but I have a generally working sdSimple implementation now, with correct hsync. It builds significantly smaller, weighing in at ~57000 bytes. It seems optimum if I just do the entire codebase around sdSimple, even if not historically correct, only PFF being available back then. I think I will go this route, even though I have a few reservations(PFF having some advantages in file handling, which weren't used here, and this being one of the few PFF examples). Not sure.

Unfortunately it seems I cannot use Jubatian's new SD API for this, as it is not designed for fast streaming(the animations get screwed up if loads are too slow). That is unfortunate because it seems to have the best SD compatibility, but even if I reworked the animations to support multiframe lags, I simply do not have 512 bytes free anywhere. Basically the fast animations only work because I load the vram map once(so now I cannot use vram as a buffer), and most require basically all the ram tiles to repeatedly reload rapidly; so that is not usable buffer either. All the ram used for gameplay state/logic put together is less than 512, so it seems something I will have to just accept.

Anyway I will at least get a version that builds correctly with the new kernel. With the savings of sdSimple, combined with the new compressed flash only "Streaming" Music(which needs a proper test application anyway), there should be a big chunk of free flash, and I think I will leave it at that. Essentially by the time I write a level editor, make new graphics to match Alter Ego 2(the existing ZX Spectrum version can be seen on YouTube, and it plainly is a better game than the original), and perform other fixes(all the AE2 mechanics were supported, but somehow don't all work now), it is basically a sequel instead of a new episode. On that note, I may not go through with all that, but if someone is interested in cooperating they would get credit plastered all over this thread, the wiki, and the opening credits screen for Alter Ego 2. Mainly I need to transcribe all the AE2 levels(which I have pictures of their starting positions) into raw data, which takes time and is error prone and boring. I estimate, and it sounds crazy high but I think accurate, by the time errors are found and fixed by comparing to original(AE is exactly to the tile correct versus NES version), roughly an hour total per level in dev time, and there are 32 levels....that is much more work than a level editor or new graphics of course, and predominantly why AE2 does not yet exist versus doing a totally new game.
</rant>
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Alter Ego

Post by Jubatian »

For the kernel I can't recall doing anything to the music player myself (that would be the last thing I touch), so for now I would say it might have been something from years ago.

The boot API might be a little more flexible than you think, check the guide for some ideas. You can point that 512 byte buffer anywhere, so you might be able to do the intro by loading from the card directly into the RAM tiles (by pointing bufp to the appropriate target for every part).

I might later add support for partial sector reads (it is possible even with CRC checking), although that would only work if you first located the sector (the traversing with FS_Next_Sector() demands a 512 byte buffer when it has to read the FAT on a cluster boundary). If you wanted to avoid glitching during the intro sequence and had enough RAM, you may preload the sector addresses used for the animation, then reading the sectors directly into the RAM tiles would only produce some "tearing" (if loading a full frame needs multiple frames). Since the image is vertically narrow, you could also use SetRenderingParameters() to trim the screen to what you are actually using there (unless you did already) which frees up VRAM and gives a lot more cycles for loading (if you did that, it would seem odd for me that you don't have 512 bytes free there as VRAM).

Syncing problems should indeed be fixed. You also have Solitaire, which has such a problem, on my display it produces some seizure-inducing flicker rendering it unplayable. When using the E-Uzebox, even having the sync just a couple of cycles off can throw my TV totally out of sync (it is more tolerant with NTSC, but Solitaire flickers even with that). I am actually thinking about making a category for "bad sync", hoping that eventually affected games could be fixed.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Alter Ego

Post by CunningFellow »

Is is possible to just graft the SdSimple "READ" function that is super optimized for speed into the new API.

Give it a name like SD_Read_Fast_No_CRC_Unsafe so people know WHAT it doesn't do.

I think all you would have to do is add a "cleanup" routine to make sure the SD statemachine was in a good state afterwards for other SD_API_NEW functions.

That would just be a stop stream I assume.

Be nice to not have to have 2 separate libs people have to choose from. And it would mean the 17 clock per byte read routine could be used with FAT32 on SDHC. Because the optimized read loop doesn't even have anything to do with the sector address that has change by the factor of 512
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Alter Ego

Post by D3thAdd3r »

Pretty much done and tested: animations, level loading, demos, etc. are all working as expected off the SD. I converted this to flash based "streaming" music, and damn...this game used to be tight on flash, now I am at 53182 bytes :shock: Could not find any difference in sound and the process was very quick to pull off. I am convinced flash based "streaming" is tested and proven now.
Jubatian wrote: Sat Jan 27, 2018 8:32 pm Since the image is vertically narrow, you could also use SetRenderingParameters() to trim the screen to what you are actually using there (unless you did already) which frees up VRAM and gives a lot more cycles for loading (if you did that, it would seem odd for me that you don't have 512 bytes free there as VRAM).
I left out an important detail there, since otherwise that is good thinking(this new version I am using SetRenderingParameters() to speed up SD setup/access). The continue screen which lets you select the level to play on, gives a full screen preview of the level and the vram is exactly as tall as it need to be for the HUD, frame, and level. On the preview, no sprite is unaligned with tile boundaries which seems then enough free ram tiles. Unfortunately, I multiplex demo data from the SD card into unused ram tiles(there is no demo for the last level, because it gets corrupted by the sprite demands). Would have to do some deeper thinking on it, maybe there is still a way.

AFAIK, I think, sdSimple at least has better SD support than PFF for "mounting". I know some people had some issues with the original SD code(and CUzebox even has a hack for it?), but I fine toothed through all of it to see what I was doing wrong. I am pretty confident I was using PFF itself entirely correctly; even had a multi-attempt mount technique which fixed some problems or would after a reset someone reported. I think those issues were underneath PFF at the low level access code, but I never experimentally proved it. sdSimple seems to work perfectly for the cards I have, but then I have just a few left anymore.

On combining libraries, do we have a rough flash size difference between the new API and sdSimple?
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Alter Ego

Post by D3thAdd3r »

Jubatian wrote: Sat Jan 27, 2018 8:32 pm For the kernel I can't recall doing anything to the music player myself (that would be the last thing I touch), so for now I would say it might have been something from years ago.
Definitely was not you, I remember I noticed that change a few years back.
Jubatian wrote: Sat Jan 27, 2018 8:32 pm You also have Solitaire, which has such a problem, on my display it produces some seizure-inducing flicker rendering it unplayable.
Eh didn't even know about that one. I will fix that up.
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Alter Ego

Post by Jubatian »

D3thAdd3r wrote: Sun Jan 28, 2018 4:08 amI left out an important detail there, since otherwise that is good thinking(this new version I am using SetRenderingParameters() to speed up SD setup/access). The continue screen which lets you select the level to play on, gives a full screen preview of the level and the vram is exactly as tall as it need to be for the HUD, frame, and level. On the preview, no sprite is unaligned with tile boundaries which seems then enough free ram tiles. Unfortunately, I multiplex demo data from the SD card into unused ram tiles(there is no demo for the last level, because it gets corrupted by the sprite demands). Would have to do some deeper thinking on it, maybe there is still a way.
On the Continue screen I see you switch by fade out and fade in. The few frames of black screen between the two screens should be fine to build up the RAM contents from the SD card, I guess. "Unfortunately, I multiplex demo data from the SD card into unused ram tiles" - what do you refer by this? I see there is stuff written into the RAM in CUzeBox, but then it shows no usage of it, and it doesn't seem like anything is happening even if I idle there. So I guess you don't mean "demo" in that sense it played the level. When selecting the level, I also only see writes on this large region, so it seems like the data loaded there isn't used at all on the level selector (Are you sure it is? What conditions would be necessary to trigger its use?). Before it never occurred to me that the game might do anything on those screens beyond allowing to select the level to play.

CUzeBox has some SD hacks in that sense that it is capable to emulate a stricter SD card. I had to loosen it (these are compile time switches with comments) since some games didn't respect one or another timing requirement allowed for the cards.

I think the new bootloader API is about 1 kilobyte, it is smaller than what the bootloader itself has (as the API only has SDSC + FAT16 without fragmentation to have something as fall-back while the bootloader supports all the new stuff).
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Alter Ego

Post by D3thAdd3r »

There 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.

As far as loose timing, in PFF you can init the card and mount a file, with no other control over how it does it. There is no way (besides vsync callbacks fiddling with SPI) that user code could do anything to modify the timing inside these functions to closer fit the spec. I think none of these issues are due to bad game code at least. I will try this new version with tighter timing and see if sdSimple inits right (where the only control is a single function call).
Post Reply