Pacman Demo

[guddler]

SO, I've never been able to get my head round scrolling!! Just to go over it again, you've got a big static image in ROM, obviously in the format that pacman hardware understands. The image is massively wide but 1 screen high.

As the most basic version then, ignoring tricky tricks to improve performance and all the rest of it (because what someone said earlier about a pointer, stack pointer I think DID make sense), to scroll the screen are you basically copying 1 screens worth into video ram (as tiles, or whatever pacman understands) and then moving the data along by 1 line / column / whatever, then tagging the next line on the right hand end?

Sorry, I know that's horribly vague!

Of course my problem is that when I eventually finish messing about with my Amigas, Vectrex and arcade PCBs, my intention is to do something with vector hardware and that doesn't have a memory mapped screen. I'd still like to comprehend this though as I want to do some stuff on the Amiga as well.

 

[Hurray Banana]

SO, I've never been able to get my head round scrolling!! Just to go over it again, you've got a big static image in ROM, obviously in the format that pacman hardware understands. The image is massively wide but 1 screen high.

As the most basic version then, ignoring tricky tricks to improve performance and all the rest of it (because what someone said earlier about a pointer, stack pointer I think DID make sense), to scroll the screen are you basically copying 1 screens worth into video ram (as tiles, or whatever pacman understands) and then moving the data along by 1 line / column / whatever, then tagging the next line on the right hand end?

Sorry, I know that's horribly vague!

Of course my problem is that when I eventually finish messing about with my Amigas, Vectrex and arcade PCBs, my intention is to do something with vector hardware and that doesn't have a memory mapped screen. I'd still like to comprehend this though as I want to do some stuff on the Amiga as well.

If I was just sticking to full tile scrolling I could do a shuffle of each column left (assuming the screen is scrolling right) and fill the vacated right hand column with the new data and that would be quite fast.

But.. I am gonna try to pixel scroll this by using 16 different tiles to represent the 8 different pixel. So I basically look up the tilemap data for the columns I need, then unpack this data (uses a bit per tile on/off - 4 bytes per column) and place all of it in tile ram. Obviously you have got to do this within one frame in order to get the smoothness.

 

[Baggers69]

Awesome update

cmonkey, you are correct!

 

[Hurray Banana]

Awesome update

cmonkey, you are correct!

That means a lot, thanks

 

[cmonkey]

Just out of interest Eric, what scan line is the raster reaching by the time you've finished the scroll routine? I'm wondering how much (or more likely how little!) time you've got left for game logic, etc? How many scan lines does your sprite routine use?

 

[Hurray Banana]

Just out of interest Eric, what scan line is the raster reaching by the time you've finished the scroll routine? I'm wondering how much (or more likely how little!) time you've got left for game logic, etc? How many scan lines does your sprite routine use?

it looks like it's taking in it's current form 180 y scanlines assuming mame is quoting y as in horizontal ones.

I'll try the copy columns and build new column method and compare it, should be a hell of a lot faster. looking at that number It might be that pixel scrolling unless I can set the tile offset data up efficiently may be out of reach, but I haven't tried yet so I don't know.

 

[Hurray Banana]

These are the other routine timings

routine | scanlines taken

=======================================

Tilemap renderer | 181

Sprite update (velocity/movement stuff) | 10

Z scaling (done separate) | 4

HurrayBanana tiles overlay | 20 (that is crappy)

|

vsync routines ==============================

Sprite blit | 3

Dynamic text | 23 (ouch!)

|

========================================

| total 241

 

[cmonkey]

So basically you've got no idle scan lines left!!!!

Hmmm, something's gonna have to give somewhere dude if you wanna get some game logic in there, otherwise you'll be forced to lock the game engine to 30fps or be faced with intermittent frame skipping.

 

[guddler]

I assumed this is demo work though and that a game would be a different project?

 

[Hurray Banana]

I assumed this is demo work though and that a game would be a different project?

the overlay is going (so that's 20 back - although I'm looking at a faster re-write), the dynamic text isn't required in the same way that it's being used now.

When I've got logic and stuff done, I'll know how much ROM I've got then I can waste some for unrolling loops.

I'm still gonna have a go at per pixel scrolling but it is looking like that will be a pure demo.

For a game I'll have to whole tile move the scrolling (like I'm doing now). If I stick to this it will mean I can do multi-directional scrolling.

I'll report back with timing on a re-write of the tile scroller.

 

[Hurray Banana]

Also you're idea for shrinking the Tile area may help a lot Ade. Might try that this afternoon.
Hurray Banana2015-03-06 14:15:49

 

[Hurray Banana]

Got the Dynamic text down to 13 scanlines
and the Hurray Banana overlay down to 11

saving 21 scanlines

Hurray Banana2015-03-06 15:16:13

 

[cmonkey]

It's just like the Tesco ad, every little helps!

 

[Hurray Banana]

Done some re-writes of scroll code as well as text rendering changes, which makes some improvements which will hopefully give me enough time to do some logic work. My next task is to move a sprite around the tilemap scrolling it with the sprite and colliding with the tiles, need to animate the sprite as well based on distance it's moved in pixels.

routine | scanlines taken
| new (old)

=======================================

|

new Tilemap renderer scroller | 93 (181)

Sprite update (velocity/movement stuff) | 10 10 - these 2 routines need combining

Z scaling (done separate) | 4 4

HurrayBanana tiles overlay | 11 (20) - 0 really as I've turned it off it's just paff

|

vsync routines ==============================

|

Sprite blit | 3 3

Dynamic text | 13 (23)

|

========================================

total | 134 (241)

total without overlay | 123 (221)

now sat waiting for vsync at either scanline 75 or at worst case scanline 87

Hurray Banana2015-03-06 21:16:08

 

[cmonkey]

Wow! That's some serious optimisation of the tilemap scrolling routine to nearly half its execution time! Well done that man! You really are loving this more than I ever imagined you would!!

Should have plenty of scope for game logic/collision detection/input handling now.

Are you noticing any graphical artifacts/tearing as you're actually moving tiles whilst the raster is turned on and in the active display area as it stands?

 

[Hurray Banana]

Are you noticing any graphical artifacts/tearing as you're actually moving tiles whilst the raster is turned on and in the active display area as it stands?

cheers Adrian, I am getting into the groove, writing instructions on paper and counting and comparing t states is so much fun, and no I'm not being sarcastic. I love counting cycles and shaving 1 here and there, don't ask me why there is some sort of satisfaction in doing this

The first version of the renderer was unpacking 112 bytes of tile data to fill the tilemap ram. Now because I'm scrolling columns of tile ram and unpacking just the new 4 bytes (one columns worth), this is giving me a massive speed boost.

What's quite annoying is that moving the viewport left (scrolling columns of tiles from left to right) is quicker than scrolling the viewport to the right by 40 T-states per column, so that is 1080 T states

, that's purely down to the tile ram layout and needing to modify addresses by $40. I need to find a different way to move the viewport to the right

scrolling left is done with 68 to 81 scanlines drawn (plus all the other crap going on)

Edit: to answer your question, somehow not really seeing tear while drawing for some reason, but that's maybe down to Mame.

Hurray Banana2015-03-06 21:52:34

 

[cmonkey]

There's nothing sad about T state counting, I do it all the time, sometimes even in my dreams!

And I agree, it's very satisfying shaving a few T states here and there, especially when it's in a big loop, the overall saving can be several scan lines worth of time.

You really could do with finding a board to test your code on though. I'd be surprised it there weren't visible artefacts from moving tiles around whilst outside of the vblank routine on real hardware. I'd hate for you to think that it's all going swimmingly well dev'ing in MAME, only to find it doesn't like quite look the part when deployed to a board. Besides that it's much more satisfying seeing your code running on a CRT in a cab than on your dev box.

 

[ben76]

I have no clue what you guys are on about lol... however keep going and if I have any pcbs for testing stuff on I am happy to lend them out or try from here burning the roms and testing

- Ben

P.S. awesome work guys

 

[Baggers69]

Glad you're enjoying coding, I really enjoyed it too! Much more fun than coding in any other language like cjava etc isn't it!

 

[guddler]

I might have a Pacman board somewhere I could lend. I fixed up and sold about 8 of them at one point but I'm sure I kept one back for my own collection.