VBXE Exercise - Popeye WIP

[woj]

Thanks guys, I will come back to you when/if needed. In the meantime, I spent literally the whole weekend plus Monday's morning figuring out the 15/16 color palette assignments for all rounds and situations, such that all palettes would be static (no need to change colors / palettes on the fly per scanline / game situation / frame, only assign palettes to color maps once per round), it seemed like an impossible task, round 1 has 19 colors in use, round 2 18, round 3 19 again, and most of those are moving objects so the corresponding colors need to stay fixed most of the time. At some point it seemed like an impossible task, but I think I now sorted it out, need to take a break for a day or so and verify it fresh before I start writing any code for this. At this point it really should only boil down to timing of the drawing and game logic for which I have ~2/3 of a frame. Not at all sure how much sound / music needs in terms of time and where / when one hooks it up, but I will worry about that later.

[Rybags]

Don't forget the attribute map - you have 4 palettes to work with so could have shared colours then vary some using attributes.

DLIs for VBXE colours - not quite as feasible as GTIA ones since you've got 3 load/stores per entry plus the initial setup there.

[woj]

50 minutes ago, Rybags said:

Don't forget the attribute map - you have 4 palettes to work with so could have shared colours then vary some using attributes.

DLIs for VBXE colours - not quite as feasible as GTIA ones since you've got 3 load/stores per entry plus the initial setup there.

Yes, precisely what I am trying to work around, not to use DLIs and make a nice static map attribute for this (so that I do not even have to change the attribute map on the fly). The attribute maps shakes together with the background on the bumps, so the palettes have to be organized such that colors between them are flipped for objects that are not too close too each other, so that there would be no color smearing. In any case, explaining this in a coherent way seems to be impossible, it took me two days to have it explained to myself  

[woj]

It seems I managed to solve the palette puzzle, now also in code, so essentially there is no wall as far as colors are concerned. I also managed to do it such that I will not need to keep duplicate copies of the same sprites with different colors (recoloring sprites when they consist of two color nibbles per byte is an absolute / impossible pain when the colors are not bit-mapped the right way), any such things can be done with proper masking when blitting. There is nothing serious on my todo list before actually getting to the character animations and game logic, so I won't escape it anymore. 

 

While developing the attached I was also thinking a bit about how faithful I should be to the original and whether I can introduce something of my own instead. For example, the screen / round transitions right now are very rough (in place direct display memory overwrite), the original game seems to be tiling the screens up / down, this is doable for sure, but perhaps I could do soft fade in / fade out stuff to use VBXE a bit more. It wouldn't look "natural" for this game though, so I need your second opinion on that. 

 

New "demo" attached. Popeye has a full color checker board attached on the side to test that the local color mapping in all rounds are correct all over the screen, when you move him you can see the tiles changing colors here and there. Keys / control:

 

Select - flip the interlace field

Option - do the screen shake (now it automatically cycles on each shake through 2 horizontal and 1 vertical)

Start - go to the next round screen (following the round sequencing of the actual game, you will also notice that in the dock and house screens the building roof on the right is modified for the witch to sit there)

 

Joystick - move Popeye around the screen

Fire - dock/house - make Popeye face red for 150 frames (round switching disabled during this time), ship - add one / next ladder step.

 

So essentially the back drops and color mappings are all fully done.

 

 

[ALEXANDER]

On 3/4/2023 at 2:03 PM, woj said:

It seems I managed to solve the palette puzzle, now also in code, so essentially there is no wall as far as colors are concerned. I also managed to do it such that I will not need to keep duplicate copies of the same sprites with different colors (recoloring sprites when they consist of two color nibbles per byte is an absolute / impossible pain when the colors are not bit-mapped the right way), any such things can be done with proper masking when blitting. There is nothing serious on my todo list before actually getting to the character animations and game logic, so I won't escape it anymore. 

 

While developing the attached I was also thinking a bit about how faithful I should be to the original and whether I can introduce something of my own instead. For example, the screen / round transitions right now are very rough (in place direct display memory overwrite), the original game seems to be tiling the screens up / down, this is doable for sure, but perhaps I could do soft fade in / fade out stuff to use VBXE a bit more. It wouldn't look "natural" for this game though, so I need your second opinion on that. 

 

New "demo" attached. Popeye has a full color checker board attached on the side to test that the local color mapping in all rounds are correct all over the screen, when you move him you can see the tiles changing colors here and there. Keys / control:

 

Select - flip the interlace field

Option - do the screen shake (now it automatically cycles on each shake through 2 horizontal and 1 vertical)

Start - go to the next round screen (following the round sequencing of the actual game, you will also notice that in the dock and house screens the building roof on the right is modified for the witch to sit there)

 

Joystick - move Popeye around the screen

Fire - dock/house - make Popeye face red for 150 frames (round switching disabled during this time), ship - add one / next ladder step.

 

So essentially the back drops and color mappings are all fully done.

 

popeye_2.xex 32.98 kB · 15 downloads

With VBXE this game will be equal than the original arcade game. Keep on the great work !

 

 

[woj]

Oh dear, there is so much pressure coming from the community to get this done, I am currently a bit stuck for # of reasons, but I keep working on it and I got some good ideas for good performance. In any case, I hope the "community" realises this will be a loooong journey 😉

[Beeblebrox]

No pressure. It's your project, your rules and time frame. 😎

[woj]

So far this was the most fiddly part, but I got it to the point where I wanted it to be. SELECT still changes interlace field, OPTION shakes the screen in different directions, currently we are stuck in screen 1, so START does not do anything. Popeye can be controlled over its allowed routes, and you can punch with fire, but this so far is visualized with his face turning red. The way he moves, falls, climbs the stairs or ladder are fully parametric, so making it closer to the original should not be a problem. In the score line you can see some debugging info, L/R for his direction facing (will be later used for proper animations) and some garbage characters to make sure the animation counters are running (or not).

 

The next thing on the to-do list is proper frame animation, TBC.

 

[woj]

Another week and a bit of progress, got the proper animations to work, and sorted out a lot of things in the code to deal with other levels and other things to come. The speeds, vectors, or exact positioning are not yet fully accurate, but fully configurable. Punching animation is not yet there (the frame has a different size and needs more code, next on the to-do), instead he just goes red and stands up in the fighting pose. Don't have a frame-grabber, so just a video made with my phone. 

 

I think I also reached the saturation point with xa65 that I've been using for this so far, I think I will have to swallow it and go mad(s), better now while the amount of code is still manageable. The executable grows, but now I am expecting it should all fit into maybe 80-90kB, though I did not count the sound in yet.

 

 

 

[solo/ng]

I hated Popeye on xl/xe because hitboxes for punching was super bad (comparing to the original). Now the superb version coming (please dun forget about it) : ).

[woj]

Not sure what you mean exactly, but I will try to keep it as close to the original as possible. I actually never liked any version apart from the arcade one.

 

I spent considerable time trying to implement a "clever" trick for splitting the character over the thru passage (in the current version the part on the left is one scanline too low and also totally out of sync with the rest of the frame) to only realize that my clever trick is in fact stupid and I should do it the conventional way. So this still needs to be done, but now I also have proper punching pose 😀 

[ALEXANDER]

On 4/2/2023 at 2:26 PM, woj said:

Another week and a bit of progress, got the proper animations to work, and sorted out a lot of things in the code to deal with other levels and other things to come. The speeds, vectors, or exact positioning are not yet fully accurate, but fully configurable. Punching animation is not yet there (the frame has a different size and needs more code, next on the to-do), instead he just goes red and stands up in the fighting pose. Don't have a frame-grabber, so just a video made with my phone. 

 

I think I also reached the saturation point with xa65 that I've been using for this so far, I think I will have to swallow it and go mad(s), better now while the amount of code is still manageable. The executable grows, but now I am expecting it should all fit into maybe 80-90kB, though I did not count the sound in yet.

 

 

popeye_2.xex 46.11 kB · 9 downloads

Keep on dong your best Woj !

 

 

[woj]

On 4/9/2023 at 12:42 AM, ALEXANDER said:

Keep on dong your best Woj !

You could have waited one day with making the video for a fresh one ;), I always try to publish something new by Sunday evening. As usual, I was hoping to have more done in a week, but again a lot of internal work was needed to get where I am at the moment, and I won't have more done during the rest of today. For the first round Popeye movements, animations, and input handling are pretty much done, you can now move around with animations trying to closely mimic the original, you can eat the spinach, and you can kill Popeye in two different ways - not picking up objects on time with 'K' and being hit by someone/something with 'L'. After dying the spinach will come back for now. 

 

New version attached, and my own short video:

 

 

 

[tebe]

On 4/9/2023 at 3:18 PM, woj said:

New version attached, and my own short video:

what is the purpose of interlace? not enough color?

[Ricky Spanish]

On 4/9/2023 at 8:18 AM, woj said:

New version attached

Wow ! Very nice !

[+Stephen]

52 minutes ago, tebe said:

what is the purpose of interlace? not enough color?

To get 480 lines vertical resolution instead of the regular 240.

[woj]

6 hours ago, tebe said:

what is the purpose of interlace? not enough color?

Original game resolution.

 

I've done a bit on the game in a week again, but nothing visual to show this time.

[woj]

Weekly update, not much exciting in terms of visuals, but the whole higher game structure is now in place, I mean choosing one/two players for the game, round transitions (not showable yet), keeping track of game state for each player, initials entering / high score, saving (and reading) score list to the disk (if started from a DOS enabled media, either the attached ATR or XEX running from SIDE3 with FATFMS enabled, for example). And looots of internal changes.

 

OPTION - switch 1/2 P game

SELECT - change interlace field (if needed)

START / Fire - start the "game"

 

Inside the "game":

K/L kill Popeye in two different ways

V - vertical shake

G/H - horizontal left/right shake

C - score 2000 points

No key to win the round as of yet, as I do not have the Popeye move geometry for rounds 2+ detailed out yet.

 

At 40000 you get extra life. 

 

Also, now before writing this up and doing some last test for today I saw there might be some random timing issues with clearing the screen and some things in the game status area not appearing correctly (which I know how to solve, just too tired today), but last I checked it did work.

 

No videos today...

 

EDIT: Forgot to say, due to some temporary fixtures in the code, it will only work with VBXE connected at $D600.

 

[+ZeroPage Homebrew]

1 hour ago, woj said:

Weekly update, not much exciting in terms of visuals, but the whole higher game structure is now in place, I mean choosing one/two players for the game, round transitions (not showable yet), keeping track of game state for each player, initials entering / high score, saving (and reading) score list to the disk (if started from a DOS enabled media, either the attached ATR or XEX running from SIDE3 with FATFMS enabled, for example). And looots of internal changes.

 

Incredible progress and the visuals and controls are really coming together nicely! Very looking forward to playing this on ZPH in the future.

 

- James

[flashjazzcat]

15 hours ago, woj said:

saving (and reading) score list to the disk (if started from a DOS enabled media, either the attached ATR or XEX running from SIDE3 with FATFMS enabled, for example).

Great work, and I appreciate the mention of FATFMS. Who knew games could utilise DOS? 

[woj]

1 hour ago, flashjazzcat said:

Great work, and I appreciate the mention of FATFMS. Who knew games could utilise DOS? 

@flashjazzcat you probably do have a good idea how much people like me appreciate your work, it is so rewarding being able to play with all these developments (U1MB, SIDE3, VBXE, all your firmware, SDrive) all at the same time. What I can say, you are not "brutal" enough advertising FATFMS, even though you have more than one video covering it, for me it was only recently that I said to myself "Oh, I see, this is how I can use it!".

 

Interestingly, it was the DOS file reading and writing (the latter specifically) that gave me somewhat of a headache for good two days. @Rybags 's VBI routine for interlace is quite time-heavy and his original code (not his fault in any way, rather my total lack of Atari experience) was totally oblivious of the critic flag. As we all know, the code for DOS file reading/writing cannot be any simpler, but file saving was working fine on SIDE3 / PBI BIOS, both for XEX /FATFMS and for mounting a bootable DOS ATR (I tried both with MyDOS and xDOS, now stayed with the latter, hat off to @tebe here I believe?). It did not work on a more real device (SDrive) or on Altirra with drive emulation. At first I thought I reused some variable on the zero page that SIO is using and PBI is not, but it turned out to be a timing issue with too heavy VBI routine ignoring the critic flag.  

 

Anyhow, yes, DOS can be useful for games indeed. My first intention was to do the game no-OS / no-DOS / wipe everything out style (like in TimePilot that I use for inspiration), but since for quite a while neither DOS nor OS is standing in my way I thought OK, let's go all the way with it and make it useful  What I did not yet try, and probably will not for a while, is to see if it would also start directly from SDX. I start high enough with my code (currently at $4000 and I do not see any danger of having to go lower), but there is probably a handful of other SDX factors I am not aware of that may stand in the way. But if it does work (still loooong way to go), hell, perhaps I can even have "Exit back to DOS" key shortcut in the game . What the game will certainly not support is a cartridge version, way too much in place code modification that I am not willing to refactor, not to mention my total lack of knowledge about cartridges  

[flashjazzcat]

40 minutes ago, woj said:

What I can say, you are not "brutal" enough advertising FATFMS, even though you have more than one video covering it, for me it was only recently that I said to myself "Oh, I see, this is how I can use it!"

I do get the feeling the functionality is overlooked by many (and regarded as an 'impractical or partial solution' by some), so you're probably right there. Seeing it used as I'd hoped is really heartening, though.

40 minutes ago, woj said:

Anyhow, yes, DOS can be useful for games indeed.

Certainly given the proliferation of extended memory these days, I suppose the option exists to migrate loaded segments there instead of requisitioning the entire memory space. You're good for a load address of $2000 (the generally agreed 'safe load address') if you ever need it without technically becoming incomaptible with any DOS, anyway (and FATFMS happens to use every byte up to $1FFF).

Edited April 24, 2023 by flashjazzcat

[Rybags]

The problem with doing the interlace is that the stuff around VSync has to be done at the exact time and it's some distance from the actual VBlank NMI.

In such a game situation the obvious thing would be to have stuff you can be doing in that interim period and check VCount once in a while then branch off to the interlace routine when time is near.

[woj]

19 minutes ago, Rybags said:

The problem with doing the interlace is that the stuff around VSync has to be done at the exact time and it's some distance from the actual VBlank NMI.

In such a game situation the obvious thing would be to have stuff you can be doing in that interim period and check VCount once in a while then branch off to the interlace routine when time is near.

I get a quite good feeling for all that by now, and I do squeeze things in there. This does not change the fact that the whole thing can (does in fact) break the SIO timing. Luckily, the score screen where the saving is done is low res / not interlaced, so I can temporary keep bailing out (not entirely, some basic odd/even frame bookkeeping has to be done regardless) of the NMI handler on critic == 1 and all is still good.

[Rybags]

Not much can be done about that - any disruption more than a few scanlines can stop SIO from working.