CRTC help - REWARD offered

[ervin]

Hi all.

As some of you are aware, I've been working on my Chunky Pixel Collision game for a while now, and I'm pretty happy with how it's going.

Except for one thing... displaying a full 16K screen is expensive!
My game is using fat pixels (of 4x4 mode 1 pixel size), so I can fill the screen quite quickly by repeating a line 3 times in software.
ie. draw a line, and then repeat it 3 more times. So in concept, I'm only drawing 50 unique raster lines, and they are repeating appropriately to fill up 200 raster lines.

But the CRTC method of repeating a line has been eating away at the back of my brain for a few weeks.
Problem is, I just can't figure it out!

I was just wondering if anyone could have a look at my program, and see if there is a way to use the CRTC to do this, to massively speed up my program.

I'm offering a reward to anyone who can help with this problem (ie. write the code that I need).
The reward is pretty decent (please PM me if interested).

Notes:
- I abuse the stack a lot during the screen drawing routine, so interrupts are disabled and enabled with alarming frequency.
- I am using a buffer to keep track of which parts of the screen need to change between frames. This has helped enormously with speeding up the program, but using the CRTC method of repeating lines would remove the need for this (minor) overhead.
- The time between screen redraws will of course vary. Does this mean that the CRTC method won't actually be possible?
- I'll provide a slightly cut-down version of the program, in order to make it easier to slot code in.

[Gryzor]

That's a first!! Wish the wiki had a fund we could use for such instances!

[AMSDOS]

Fraid it's over my head if it's CRTC based. Though I get paid to enjoy the work I do, so I guess that levels the ledger! 

[ervin]

That's a first!! Wish the wiki had a fund we could use for such instances!

That would certainly be fabulous, but this problem is driving me nuts, and I'm more than happy to pay for the help! 

[arnoldemu]

repeating 3 scanlines I think will be very processor intensive and may not fit in with your code and your use of the stack.
the address would need to be re-written every 3 lines.

it's much easier on the plus.

this repeats char lines, but no help to you, but I'm thinking of ways to help:

5 rem repeats char lines, 16 char lines tall; relies on way crtc is hooked up in cpc.
6 rem screen can be 8k with repeated char lines
10  out &bc00,9: out &bd00,15
20 out &bc00,4 : out &bd00,19-1
30 out &bc00,7 : out &bd00, 15
40 out &bc00,6 : out &bd00, 12

[redbox]

But the CRTC method of repeating a line has been eating away at the back of my brain for a few weeks.

As far as I remember, even though your routine used chunky sprites, the movement was pixel (or maybe byte) based.  If you use the CRTC to do the magnification, then a problem would be that you would also only be able to move them about in the magnified sized increments too...?

it's much easier on the plus.

Do you mean by using the programmable interrupt to do it?

[MacDeath]

But the CRTC method of repeating a line has been eating away at the back of my brain for a few weeks.
Problem is, I just can't figure it out!

How fun.
I came to theorize the 16 coloured square pixel 160x100 mode.
this also give the potential to have the Graphic datas weighting half, if you manage to re-draw each line...


But I don't know shit about proper coding so it is still in dreamland.

Good to see you are trying something similar (yet a bit more chunkier indeed....)

Yet this can be quite tricky to get such thing done, and even eat a lot of CPU actually.

a shame.
CPC is capable of converting "horizontal" coding from monochrome Mode0 code to monochrome Mode1 code, often used in speccy ports or for simple character fonts (letters and so on).

but there we deal with vertical stuff...

[ervin]

repeating 3 scanlines I think will be very processor intensive and may not fit in with your code and your use of the stack.
the address would need to be re-written every 3 lines.

That's what I was afraid of. 

[ervin]

As far as I remember, even though your routine used chunky sprites, the movement was pixel (or maybe byte) based.  If you use the CRTC to do the magnification, then a problem would be that you would also only be able to move them about in the magnified sized increments too...?

All movement is based on the chunky pixels.
So in my game, moving horizontally one "pixel" means moving by one byte.
Moving vertically one "pixel" means 4 raster lines.

[arnoldemu]

Do you mean by using the programmable interrupt to do it?

I would use a DMA list because you can setup the interrupts much more easily to happen every 3 lines.
then in the int routine just update the stuff.

if you used raster ints, you have to reprogram the raster int each time you want a new one.

then I would probably try split screen to do it.

then find that the memory refresh fails (because it relies on ram access for screen) and the cpc looses the information in it's ram 

[ervin]

I came to theorize the 16 coloured square pixel 160x100 mode.
this also give the potential to have the Graphic datas weighting half, if you manage to re-draw each line...

Indeed, the saving on graphical data memory, along with the speed boost I've managed to get, are the main reasons behind the technique.

[MacDeath]

Well, despite originally fewer Data are to be "processed", the Z80 still have to write the big 16K in "VRAM" zone (even more if you consider fullscreen as an option)

While you only move on blocky pixel 1byte farther...
the CPC must still "erase" this 1byte and rewrite it elsewhere... (in the case of a moving sprite perhaps).


CPU Vs Memory... hard bargain, as CPC often lack in both...

[ervin]

Well, despite originally fewer Data are to be "processed", the Z80 still have to write the big 16K in "VRAM" zone (even more if you consider fullscreen as an option)

While you only move on blocky pixel 1byte farther...
the CPC must still "erase" this 1byte and rewrite it elsewhere... (in the case of a moving sprite perhaps).


CPU Vs Memory... hard bargain, as CPC often lack in both...

That's right, and I've done almost everything I can to make my display routines fast enough for a full-screen display! Moving by one byte at a time eliminates the need for any sort of masking. That was the very first idea behind the chunky pixel technique I'm using, and that idea along with stack abuse made a relatively high-speed full-screen display feasible.
I've been searching for a faster method for a few months now. I've tried all sorts of things, and algorithm improvements have indeed led to further speed-ups. But in the back of my mind, I feel like it can always get better. The eternal dilemma!

[redbox]

All movement is based on the chunky pixels.
So in my game, moving horizontally one "pixel" means moving by one byte.
Moving vertically one "pixel" means 4 raster lines.

Sorry, was remembering it incorrectly!

The Batman Forever does some chunky pixel moving and zooming (at time 6:33):

Maybe this is worth disassembling?

[andycadley]

It might be feasible to do in a game, but it would very much be a case of structuring other code around the display handler rather than the other way around. It's certainly not something you could just "slot in", unless you don't need any of the display time at all to do processing (which is unlikely given the aim is to be speeding things up).

[ervin]

It might be feasible to do in a game, but it would very much be a case of structuring other code around the display handler rather than the other way around. It's certainly not something you could just "slot in", unless you don't need any of the display time at all to do processing (which is unlikely given the aim is to be speeding things up).

Ah, I see. 
As this thread has developed, I started having a feeling that something like that would be the case.

Ah well, thanks for your input everyone!
I shall continue on with the software rendering method I've been using!
At least I won't be chasing a ghost anymore.