Pacman Demo

[Hurray Banana]

Ok another update

Decide to see if I could do something a little bit more impressive than scrolling illusions.

So here goes horizontal scrolling tilemap: 256 tiles wide x 32 tiles high

looks a bit jerky as I'm working with whole tiles and updating every 16 frames in this example, but I have more ambitious plans than this. Again looks better in 480p60 resolution

the draw routine is not optimised yet don't know how much speed increase I can get in here, my skills are a little rusty still.

what do you think?

Hurray Banana2015-03-05 13:18:08

 

[Baggers69]

Awesome well done

 

[Hurray Banana]

Awesome well done

Cheers Jim,

I can speed this up if I don't write to the pallete ram, so that's good for the next step

 

[Baggers69]

Yeah, if it doesn't change, no point wasting a huge amount of cycles updating it

 

[cmonkey]

Looking good Eric.

What method are you using to shift the data? Hopefully not ldir, as it's a pretty slow way of shifting data around. Maybe you're using unrolled ldi loops or better still point your stack at the end of tile ram and constantly push the new tile data onto the stack for the fastest method.

 

[Baggers69]

Are you scrolling the video ram then just updating the edge?

 

[Hurray Banana]

@Ade forgot about pushing, (this is where my z80 is rusty) will look at that, I've got a long unrolled loop for each column of tiles to unpack the tilemap data and place into the tile ram

@Jim I wasn't scrolling the vid ram, but I will be in the future if I can get some benefit. At the moment just doing a full unpack of data from an offset in the tilemap table and chucking it into tile ram from right to left so I only have to inc hl which is pointing at tile ram. I wondered if I could do it quick enough.

Gonna try scrolling video ram but this is only gonna work for 8 pixel jumps, I want to try and get this working using per pixel scrolling using the same technique I did with the checkerboard, but don't know whether I can do that fast enough (yet - that's the fun part).

If I can get this working I should be able to create a little dungeon game.

 

[ben76]

Great work

- Ben

 

[Hurray Banana]

Great work

- Ben

Cheers Ben, I'd forgotten how much I love Assembly language.

 

[Baggers69]

If you're doing the pixel scrolling, you're going to have to update the whole screen each frame, so won't be able to scroll the VRAM
Should be possible though! shame the VRAM is ordered down screen first rather than across, as that would help with getting to the next byte.

I'm getting some crazy ideas of how to approach it in my head too now thanks lmao

 

[Hurray Banana]

If you're doing the pixel scrolling, you're going to have to update the whole screen each frame, so won't be able to scroll the VRAM
Should be possible though! shame the VRAM is ordered down screen first rather than across, as that would help with getting to the next byte.

I'm getting some crazy ideas of how to approach it in my head too now thanks lmao

Yeah I've gotta adjust the values dumping into vram based on the 8 pixel offset for current scroll position and do a full write. The video ordering is a pain really.

 

[Baggers69]

haha yup

 

[Hurray Banana]

Ok done some messing to get this smoother. It's running at 60fps (although I'm scrolling every other frame in this one so it's not moving too fast). I'm quite pleased with the smoothness here. Thanks to Ade and Jim for input, you are both inspiring me to flex me brain.

this tilemap is 2048 pixels wide (512 tiles) by 256 (32 tiles) high taking 2K of ROM.

In fact I've done so much assembler over the last couple of weeks that I keep using semi-colons for comments when I've been helping the students with their code in C# and Java, in fact I did it every time I did some code with them today

I'm still mulling over in my head how to implement the pixel scrolling and it involves tracking 16 pixel offsets not 8 so it's a little trickier than I would like, so I'm getting me subconscious to think about that one while I think about moving a sprite around with collision detection and other sprites with tracking abilities. As the screen is scrolling I should be able to get away with a fair more moving sprites than I need to render on screen so I can stick to the 6 hardware sprite limit.

Again best to watch in 480p60 (change it then restart the video), apologies for the short vid but fraps took 500MB to snap this, so it takes a few minutes to upload at home. (at work we've got a 75Mb upload so I can record longer ones during work).

Hurray Banana2015-03-05 21:17:05

 

[cmonkey]

Have you thought about maybe not scrolling the entire screen but instead scroll a smaller window and put a static border around the edge of the screen. That way you can avoid having to deal with scrolling the weird vram layout and you'll also get much better performance. Many Speccy games resorted to this trick to get an acceptable frame rate.

Correct me if I'm wrong Baggers but I believe the scrolling area of Midnight Resistance was 208x128 (26x16 chars) which is 26624 pixels to shift. That's a fraction over half of the available pixels of the Spectrum screen (49152).

You may want to consider this approach Eric.

 

[Hurray Banana]

Have you thought about maybe not scrolling the entire screen but instead scroll a smaller window and put a static border around the edge of the screen. That way you can avoid having to deal with scrolling the weird vram layout and you'll also get much better performance. Many Speccy games resorted to this trick to get an acceptable frame rate.

Correct me if I'm wrong Baggers but I believe the scrolling area of Midnight Resistance was 208x128 (26x16 chars) which is 26624 pixels to shift. That's a fraction over half of the available pixels of the Spectrum screen (49152).

You may want to consider this approach Eric.

That is a nice idea Adrian, It might be something to think about once collision checking for a number of sprites starts nicking cycles. I could use the unused space for UI elements.

 

[cmonkey]

That's absolutely brilliant dude! I doff my hat to thee! That's gotta be the best demo I've ever seen on Pac Man hardware! You've made the impossible possible by sticking at it. Well done sir!

 

[Hurray Banana]

That's absolutely brilliant dude! I doff my hat to thee! That's gotta be the best demo I've ever seen on Pac Man hardware! You've made the impossible possible by sticking at it. Well done sir!

Thanks for inspiring me to dust off my assembler programming, I am f**king truely loving it. I owe you a beer

 

[Nes4life]

That's some pretty smooth scrolling, with a lot going on, on some pretty limited hardware! I bet there's more to come too. Can't wait to see what this mutates into.

 

[Hurray Banana]

That's some pretty smooth scrolling, with a lot going on, on some pretty limited hardware! I bet there's more to come too. Can't wait to see what this mutates into.

cheers mate.

I have a bad tendency to get bored after doing the complicated interesting stuff so I need to keep finding tricky problems to keep me going. I am keen to get something working even if it's not polished.

 

[cmonkey]

Thanks for inspiring me to dust off my assembler programming, I am f**king truely loving it. I owe you a beer

I'll take you up on that beer one day!

Well I did put in my L System tech demo that I hoped it would INSPIRE more people to start homebrew coding for arcade hardware. Looks like it's worked for at least one person...