Jump to content
IGNORED

VBXE Exercise - Popeye WIP


woj

Recommended Posts

I am actually a bit hesitant to start the topic not to jinx it, and that early in the project too, but I figured it would motivate me to go on with this. My plan - do a 1:1 replica of Arcade Popeye on VBXE. Preliminary research tells me that using the 480i mode by Rybags it can be done, for the first level I am 99% certain by now, below the picture of what I have so far (the stairs and roof shadow are coming soon too, I need some sprites for that, too tired today, and yes, my LCD screen needs a bit of color tune down). I am learning things as I go, I did far from trivial things in a couple of assembly languages before, but not yet on 6502 (the "complicated simplicity" of it annoys me ;)) and never a game. 

 

I will probably fail eventually (also due to lack of time) and even if I don't, I know there are things I cannot do, sounds and music is for one, so I may need help at some point. 

frame.png

20230216_214013.jpg

  • Like 20
  • Thanks 1
Link to comment
Share on other sites

Not sure you'd get a 1:1 replica.  Arcade Popeye looks to be 512x448 and occupies most of the screen horizontally.

The graphics look to be cell-based, 32 across?  Maybe you could stretch the cell to 20 pixels instead of 16 which would give 640 resolution.

Narrow mode in VBXE hires will give 512 but then the aspect ratio will be squashed horizontally.  Of course you could rework the design to compensate.

Vertically you should be OK.  448 is equivalent to a a blank character line top and bottom on Atari so shouldn't clip too much.

  • Like 1
Link to comment
Share on other sites

It is exactly 512 x 448 and the original game indeed seems to be 4:3 or close to that. I have never actually considered keeping that original AR, my goal is pixel to pixel copy. 

 

What I could do, have to dwell on it a bit, at least the first screen can be easily extended horizontally by adding extra floor tiles, and then go normal width with vbxe rather than narrow.

Link to comment
Share on other sites

I know visually this is not much more than last time, but underneath I have the whole playfield recolored using map attributes. Still struggling with some fine details about scrolling to be able to shake the background, but I am on my way there...

frame.png

  • Like 5
Link to comment
Share on other sites

No, he is not yet moving, that is actually not too difficult to do, just cook up a blitter list and that's it. I am currently working on juggling the main and vbxe memory in the right way and setting up the background and the color mapping such that I can scroll it 8 scanlines down, and 8 pixels left / right to have the shakes when Bluto jumps or hits the sides. That will get me very close to have the backdrops for the levels all setup and will leave me with the main play field. The small added difficulty here is that on the third screen the backdrop also gets modified during the game (building up the ladder), so the structures for this cannot be fully static.

 

As it turns out, the 512K of RAM on VBXE is not that much, this game has a lot of high-res sprite frames, all this will have to fit in there. What adds to the problem is that there is one huge thing missing in the VBXE I just found out. Namely, there is no nibble by nibble blitter option for the high-res mode (only for detecting collisions). In effect, I cannot easily (fast) move VBXE sprites with 1 highres horizontal resolution, and I cannot easily make mirror images for when the characters are moving in the two directions. For full byte per pixel graphics this is trivial, mirroring is blitting with the destination step -1, with high-res where each byte is two pixels mirroring this way puts Popeye behind jail bars ;) 

 

Don't have any new visuals, but under the hood the code is taking shape slowly...

  • Like 2
Link to comment
Share on other sites

1 hour ago, woj said:

What adds to the problem is that there is one huge thing missing in the VBXE I just found out. Namely, there is no nibble by nibble blitter option for the high-res mode (only for detecting collisions).

I assume this is Mode 6 you are referring to?  If so, good to know.  I'm messing a lot with VBXE and the next thing I needed to do was try the 640 pixel mode.

Link to comment
Share on other sites

@Stephen Yes, I meant the mode 6. Reading the docs more I also realized the zoom feature does not work with hires either, which makes life really difficult for me.

 

I have a question for @Rybags, in this piece of code (part of your MemoPad demo and the VBXE 480i picture display program):

 

vblankend
	lda sdmctl
	sta savesdmctl
	lda #$20
	sta sdmctl
	sta dmactl
	lda #$80
	sta wsync
;	sta porta
	.byte 234,234,234,234
	.byte 234,234,234,234
	.byte 234,234,234,234
	jmp $e45f

 

What was the intention behind savesdmctl? It is not read anywhere (in either of the two programs)?... And the 12 nop-s, what are these for? Finally, is the timing of the dmactl := $20 assignment critical here (can I remove the savesdmctl business I mean). I know I can test, but as I said in the other thread, I do not own a real CRT, so even if it does work for me, it might not in general.

Link to comment
Share on other sites

Savesdmctl would be to just preserve the shadow DMA register - this was probably just for testing.

The NOPs are timing.

The store to PORTA - I was doing oscilliscope readings when developing the 480i mode, and using a wire from the joystick as the sweep trigger.

It's not needed for the video generation at all - likely a bunch of that stuff could be removed.

There should be a few VBXE 480i pics around somewhere - they might have the code trimmed.

  • Like 3
Link to comment
Share on other sites

I think it's time to post the first executable, I essentially nailed the backdrop drawing and shaking it. On top of all that i also have a Python script to help with backdrops for rounds 2 and 3, so these now require only some hours with graphics program.

 

Keys:

Select - swap the interlace fields

Start - Cycle the screen shake direction (down, left, right)

Option - do the shake

 

I wouldn't mind if somebody told me if it works on an actual CRT screen, I only have an older LCD TV at my disposal.

 

Next thing will be to move the static Popeye sprite with the joystick and start on the proper game loop code. From this point on it gets a bit steep, because I need to figure out some way of fitting in all the sprites in the VBXE RAM such that it will be relatively easy to operate on them.

frame.png

popeye_2.xex

  • Like 6
Link to comment
Share on other sites

2 hours ago, woj said:

Yes, that's precisely what the problem is, you are viewing the images of the Basic rom instead of tile characters ;) 

Oh good grief! I forgot I switched profiles on the U1Mb - I always run with BASIC off 🤦‍♂️

 

Looks great now!


C829DC43-3B69-4F1D-B6C4-52F1AA25BB2C.thumb.jpeg.524bbc9c198aaa5fdcc9bb08ca738246.jpeg

 

  • Like 4
Link to comment
Share on other sites

OK, absolutely sweet, thanks @spookt! (I really need to get my hands on a CRT).

 

I have most of the stuff worked out in my head, and it is generally going faster than I thought, yet it is still a looooot of work. 

 

Yes, VBXE is really cool, if only the hi-res mode was treated a bit more in depth, I could really use some features that are there for the "normal" 320x240 mode. And I am not talking about 16 colors only, this is perfectly fine, it is clear that the authors of the original game had to deal with the same exact limitation. 

  • Like 1
Link to comment
Share on other sites

Progress, the Popeye can move! Again, visually this is just an object moving around the screen compared to the previous one, internally, however, that required a bit of code reconstruction and proper screen buffering (I know this is sort of obvious for the seasoned game developers around here, for me this is new, in practice I mean, the theory I am familiar with ;)). The biggest question now is how many objects can I operate within one frame before I run out of cycles. I already know that when I call a blitter during vblank to clear the next half-screen I cannot wait for it to finish in the interrupt, it takes considerably longer to blit 256x240 pixels than the VBI has time for before it hits Rybags timing code.

 

Anyhow, attached two flavours, one moves slower (1 pixel / frame) and stays in the the bounds of the screen, the other one moves at 2 pixels per frame and can cross over horizontally. 

pop_step1.xex pop_step2.xex

  • Like 3
Link to comment
Share on other sites

2 hours ago, woj said:

I already know that when I call a blitter during vblank to clear the next half-screen I cannot wait for it to finish in the interrupt, it takes considerably longer to blit 256x240 pixels than the VBI has time for before it hits Rybags timing code.

I'm sure you already know this, but when just wanting to clear, make sure you're using Blitter Mode 0, and use a blt_and_mask of 0 for maximum speed.  I have not done speed tests yet to see if using zoom with a lower number of pixels is faster, slower, or same size as using zoom of 1 and clearing all pixels.
 

  • Like 1
Link to comment
Share on other sites

Yes, I do know all this, I read the manual in both languages several times just to be sure I do not miss things like this. Whether I implemented it right is another question ;) I keep making very silly mistakes out of unfamiliarity with 6502 that make me go into endless loops of hunting down really idiotic bugs.

 

I've read somewhere around here that the zoom feature reads the source several times, but then the 0 mask should skip the source anyhow, so perhaps indeed it might be a good idea to try it. 

 

In the worst case my contingency plan is to clear only the areas that were drawn, this would require a bit of ugly book keeping though, but then it would be no more that 25% of the screen area I gather.

 

In fact, the more I think about it, the more I am convinced it's a way to go anyhow, considering there are some elements that do not move at all, or move seldom.

 

  • Like 1
Link to comment
Share on other sites

Your clear screen - don't start in VBlank.  Better off having a DLI near the bottom of the active display.

You could calculate the exact place, it could potentially be about 4/5ths down the screen.

A clear-screen blit will be hitting one VRam location per available VBXE cycle.  That's 64,000 VBXE cycles if it's a 200 scanline normal width overlay.

There's 912 cycles per scanline, minus whatever the graphics or CPU steals.  The CPU and Antic only steal cycles if accessing VRam through a banking window.

 

  • Like 1
Link to comment
Share on other sites

@Rybags you have no idea how much I appreciate this kind of feedback, thanks! When you said it, it became so obvious ;)

 

I experimented a bit. First, using the zooming feature in the blitter does not speed up things at all. Second, for me and how I have the game frame syncing organized I need to start clearing about 2/3 down the (visible) screen, this way I have the blitter idle before my next drawing starts. I can most probably delay this by one DLI as I first do some pre-computations and do not need the blitter right away, but in any case, I managed to ballpark it. And it is late enough (1-2 DLIs to spare) not to start erasing things before they are drawn.

  • Like 1
Link to comment
Share on other sites

The zoom can speed up to an extent in that the source data isn't needed to be fetched as often, though I think that only applies to horizontal stretches and subsequent scanlines e.g. in a 4x4 scenario would need each horizontal element fetched again.

 

Part of pre-planning should be to work out the requirements for rendering then decide what method to use.  Double-buffer, erase/redraw, save/restore sprites etc.

Though whatever way you end up going you'll probably hit a wall sooner than you think.

The graphical capabilities are a big leap over stock but the multiplier effect in terms of clock speed insofar as what the blitter + CPU can get done doesn't necessarily match the jump in graphics ability.

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...