CPCWiki forum

Hi all.

I'm several weeks into the development of a new game, which I have named "Chunky Pixel Collision" (see what I did there?)

I've been spending pretty much all the dev time thus far on writing the engine.
It features big fat chunky pixels, being thrown around pretty fast on a full-screen mode 0 display.
Also, sprites displayed in this system are clipped to all four screen edges correctly.

The pixels are twice the width of a mode 0 pixel, and 4 times as high.
A chunky square, in other words.
So effectively a full-screen resolution of 80x50 "pixels".

There are two reasons I went down the path of big fat pixels.
1) Performance. I've written a routine that fills 8 mode 0 pixels really quickly (ie. one of my fat pixels).
2) It looks really cool (if you like that sort of thing).

I don't want to announce the style of game I'm hoping to create just yet... in case I fall flat on my face.

Anyway, I wanted to put together a little demo for anyone that is interested.
I tried to think of the biggest, chunkiest cpc sprite around.
Who would you think of?

Well, I thought of the man himself, Savage.

I've been itching to show this to you all, so please download the dsk and have a go!
He can be moved around the screen using the cursor keys.
He clips correctly on all four sides, and he is completely redrawn every frame.
I'm getting around 10 frames per second at the moment, but there are some major optimisations I plan to incorporate (once I figure out how to do them!).

Can someone please try this on a real cpc?
I'm not sure if it will work on a 464, though.
Thanks.

Hey Ervin, I gave you a greeting in my new demo (http://www.cpcwiki.eu/index.php/Xmas_2010_Demo) about your programming, so you've replied quickly!

Looks interesting and works on my 6128 Plus.

What optimisations are you working on?  I see lots of IX registers in your code which are useful but slooooooow in a loop.

Run perfectly on a 6128 type 1 and 6128+  ;)
It is an interesting concept , i am keen to see how you'll use it.

.

Quote from: redbox on 16:09, 15 December 10
Hey Ervin, I gave you a greeting in my new demo (http://www.cpcwiki.eu/index.php/Xmas_2010_Demo) about your programming, so you've replied quickly!

Looks interesting and works on my 6128 Plus.

What optimisations are you working on?  I see lots of IX registers in your code which are useful but slooooooow in a loop.

Thanks for the greeting in your demo! That's the first time I've ever been referenced in a cpc production! Very nice demo too.

The optimisations involve figuring out how to only draw the bits of the screen that change between frames. As you will no doubt remember  ;) , I spent a fair bit of time researching that concept during the 3d-maze development. I'll try to use those ideas in chunky pixel. That should make it run much faster.

Did you disassemble the code?  :)
IX and IY are used as extra registers during the part of the program that draws the screen.
I do 8 pops (to retrieve the sprite data), and then 4 sets of 8 pushes. 4 rows of 16 fat pixels are taken care of this way.

The code looks a bit like this:


pop af
pop de
pop bc
pop ix
pop iy
exx
pop hl
pop de
pop bc
exx

ld sp,hl
exx
push bc
push de
push hl
exx
push iy
push ix
push bc
push de
push af


SET and RES (thanks to Axelay for the SET 3,H idea) are used to move to the 2nd, 3rd and 4th raster lines for each "pixel".

Quote from: fano on 21:01, 15 December 10
Run perfectly on a 6128 type 1 and 6128+  ;)
It is an interesting concept , i am keen to see how you'll use it.

Cool, thanks for testing on real machines.
I wish I could do the same.    :(

Quote from: phi2x on 21:23, 15 December 10
I think I know what you're about to do. 8)

I watched your demo on CPCBox, runs great on it! It immediately bringed back some memories of a certain Amiga game that was deemed impossible to do. The name starts with Gl.... ;)

:-\  I probably shouldn't have hyped this up like I did (I was just so excited to have created something kinda cool).
Having a cpc version of Gloom would be amazing (that was a GREAT game, by the way), but my skills and mathematical knowledge just aren't up to it.

My game concept is indeed 3D, but not raycasting 3D. More along the lines of space harrier, without the shooty bits.

Now I'm off to optimise it, before getting to work on the 3D stuff itself!

Quote from: ervin on 23:58, 15 December 10
Thanks for the greeting in your demo! That's the first time I've ever been referenced in a cpc production! Very nice demo too.

Thanks, glad you enjoyed it!

Quote from: ervin on 23:58, 15 December 10
The optimisations involve figuring out how to only draw the bits of the screen that change between frames. As you will no doubt remember  ;) , I spent a fair bit of time researching that concept during the 3d-maze development. I'll try to use those ideas in chunky pixel. That should make it run much faster.

This is what I thought of as I remember discussing it before and you said that you draw the whole sprite each time.  I guess only drawing the bits that change largely depends on how much it needs to move each frame - if you are moving it by one whole fat pixel (infact I think I saw it moved more than that when I pressed a key) you might not have as much overlap...?  Testing would be the only way to find out!

Quote from: ervin on 23:58, 15 December 10
Did you disassemble the code?  :)
IX and IY are used as extra registers during the part of the program that draws the screen.
I do 8 pops (to retrieve the sprite data), and then 4 sets of 8 pushes. 4 rows of 16 fat pixels are taken care of this way.
SET and RES (thanks to Axelay for the SET 3,H idea) are used to move to the 2nd, 3rd and 4th raster lines for each "pixel".

Yes, I had a quick look and looking again now I see you've got some cool stuff in there - use of the stack, alternate registers, the SET and RES trick - great stuff.  I guess your optimisation will largely depend on the draw/not draw routines above then  :)

Yes, the code I uploaded moves Savage 2 "pixels" at a time, by referencing a moveAmount variable.

Yeah the optimisation and algorithms I've used so far have been based on a lot of trial and error, and a heck of a lot of help from stuff I've learned here on these forums.
What an amazing resource.

Just imagine what the devs 20+ years ago could have come up with if they had such a great knowledgebase at their fingertips...

Nice effect!  :)  Will be interesting to see how it develops further into a game.


I tried it on my unexpanded CPC464 and it seems to work just fine.


Also, sorry to pry into your code (but you mentioned using set 3,h and I couldnt help myself but have a little look) but I noticed you have done the lines in 'numerical' order, 1,2,3,4,5,6,7,8 - which sometimes requires multiple sets/resets.  I didnt look into the code enough to see the wider view of how it all works, but could you not do the lines in the order that only requires a single set or reset to get to each new line and save a little time?


like this say:


do line 1
set 3,h
do line 2
set 4,h
do line 4
res 3,h
do line 3
set 5,h
do line 7
set 3,h
do line 8
res 4,h
do line 6
res 3,h
do line 5

Quote from: Axelay on 12:29, 16 December 10
do line 1
set 3,h
do line 2
set 4,h
do line 4
res 3,h
do line 3
set 5,h
do line 7
set 3,h
do line 8
res 4,h
do line 6
res 3,h
do line 5

This one is great , if you agree , i am going to borrow it to get a little further optimisation  ;D (crap ! i'll have to rewrite some tools code)

Quote from: fano on 12:43, 16 December 10
This one is great , if you agree , i am going to borrow it to get a little further optimisation  ;D (crap ! i'll have to rewrite some tools code)

I agree. this is great.

Quote from: arnoldemu on 12:44, 16 December 10
I agree. this is great.

Me too.

For this to work, the first line still has to be locked to an even address line though (assuming y=0 to start)...?

But for compiled sprites, it's quite an optimisation.

Quote from: Axelay on 12:29, 16 December 10
do line 1
set 3,h
do line 2
set 4,h
do line 4
res 3,h
do line 3
set 5,h
do line 7
set 3,h
do line 8
res 4,h
do line 6
res 3,h
do line 5

Thanks Axelay.
Glad to hear that it works on a 464 - although that may not be the case in a little while, as there will hopefully be many, many sprites in this game, and for that I'll need to learn how to use the extra memory banks of the 6128.

With the set/res stuff, I originally did have it like that, and only had one set or res per line change.
The problem was the there was the very occasional venetian blind effect appearing and making the screen tearing far more obvious (I've accepted the screen tearing as I won't have enough memory to do double buffering).
So I changed it to go from the top line to the bottom within each section. The speed penalty was small enough to be excusable.

Now I'm gonna try and figure out a way to store the huge Savage sprite in half the number of vertical columns, thereby halving the memory to store him. Sounds easy... except that catering for clipping on the left and right complicates matters... oh the joys of brain exercise!

.

Quote from: phi2x on 14:17, 16 December 10
It is also possible to do the rasterline height stretching by hardware instead of using the z80. That would give you tremendous speedup.
You should check the CPC demo called "Overflow's Backtro". The technique used there is based on the following CRTC trick: if R1 has a higher value than R0 then the CRTC video repeats the same line again and again.

Don't know how practical it would be for a game though. That technique needs precise synchronizing of your code with the CRTC, switching R1 value every four rasterlines.

Now that does sound interesting!
Unfortunately it may be beyond the scope/intent of this project, and certainly beyond my skill!
I'm still pretty new to z80 coding, so I'll probably have trouble figuring that sort of thing out.

Quote from: ervin on 13:49, 16 December 10

With the set/res stuff, I originally did have it like that, and only had one set or res per line change.
The problem was the there was the very occasional venetian blind effect appearing and making the screen tearing far more obvious (I've accepted the screen tearing as I won't have enough memory to do double buffering).
So I changed it to go from the top line to the bottom within each section. The speed penalty was small enough to be excusable.

Ah, that makes sense.  I thought I was seeing tearing so that it wasnt double buffered, but I didnt twig to the implications of that for a process that takes longer than a frame.  Bummer.  You really going for 128k only and still not enough ram for two screens though?  Yikes!

Quote from: redbox on 12:53, 16 December 10
Me too.

For this to work, the first line still has to be locked to an even address line though (assuming y=0 to start)...?

But for compiled sprites, it's quite an optimisation.

Yes, in Dead on Time, the sprites were either locked to every second or fourth address line depending on the need for the sprite, so they would be y val 0,2,4,6 etc, or 0,4,8,12 etc.  I think fonts are the only things I've locked to whole character lines though.

Quote from: Axelay on 14:53, 16 December 10
Ah, that makes sense.  I thought I was seeing tearing so that it wasnt double buffered, but I didnt twig to the implications of that for a process that takes longer than a frame.  Bummer.  You really going for 128k only and still not enough ram for two screens though?  Yikes!

Yeah, I'm going for a crazy number of sprites in this one, and I want to do it without post-loading disk access.
All part of the fun!  :)

Quote from: Axelay on 14:53, 16 December 10
You really going for 128k only and still not enough ram for two screens though?

So if you use 128kb then you page in the last 16k of the extra 64k to &C000 for double buffering...?

And this would mean all your routines could be hardcoded to &C000...  If so, I never thought of this (for some reason).  Drawback is of course it's 128kb only.

.

Quote from: redbox on 15:05, 16 December 10
So if you use 128kb then you page in the last 16k of the extra 64k to &C000 for double buffering...?

And this would mean all your routines could be hardcoded to &C000...  If so, I never thought of this (for some reason).  Drawback is of course it's 128kb only.

I'm planning on storing the sprite data in the extra banks, and paging that in as required.
I have no idea how to do this... but I'll do my best to figure it out!

Quote from: phi2x on 15:22, 16 December 10
That won't work, the gate array doesn't have access to mapped RAM! It can only use the plain unmapped first 64KB of RAM.

Oh well, nice idea.  Thanks for letting me know  :)

Okay, some progress has been made.

I had to change the data structure that stores the sprite info, to make it flexible enough for what the sprites will need to do.

This meant also rewriting the sprite manipulation+positioning+clipping code as well.
That was fun.  ???

Anyway, it seems to work perfectly now.
I hope.

The only drawback is that it is very slow. Slower than a snail pulling a caravan, in fact.
It's running at around 3.6 fps at the moment.
Luckily it is completely unoptimised C-like code (using the brilliant ccz80 compiler), which was done in order to figure out some really efficient algorithms.

Now it's time to convert it to machine code, and make those z80 registers work hard!

When you're referring to using a crazy number of sprites in this game, you're not talking about having many sprites onscreen at once? Having many on the screen at once (even when using Assembly), will ultimately slow down the program! :( This mightn't be a problem on the Plus if that's what your using - personally though I'm not sure.

Quote from: CP/M User on 06:12, 21 December 10
When you're referring to using a crazy number of sprites in this game, you're not talking about having many sprites onscreen at once? Having many on the screen at once (even when using Assembly), will ultimately slow down the program! :( This mightn't be a problem on the Plus if that's what your using - personally though I'm not sure.

The version I was working on before I put Savage in contained 12 Miner Willy sprites, that were 64 pixels tall (that's 64 normal pixels, as opposed to the chunky pixels I'm creating).
They were moving around the screen at around 11-12 fps.
That didn't contain the final big optimisation I plan to make.

Having lots of large-ish sprites on the screen at once is looking possible.  :)

ervin wrote:

The version I was working on before I put Savage in contained 12 Miner Willy sprites, that were 64 pixels tall (that's 64 normal pixels, as opposed to the chunky pixels I'm creating).
They were moving around the screen at around 11-12 fps.
That didn't contain the final big optimisation I plan to make.

Having lots of large-ish sprites on the screen at once is looking possible.  :)

Well I guess it may depend on how much stuff you've got going in your game. The game I'm thinking of uses Colour Switching, Scrolling Backdrops and large-ish sprites which slows down a little bit when too much is on screen - some people on the scene has critised this and trash the game, but it doesn't bother me, I'm more bothered by the number of times I've completed it - and critics call it too difficult (I better not name the game otherwise I'll get branded!).

Quote from: ervin on 07:38, 21 December 10

The version I was working on before I put Savage in contained 12 Miner Willy sprites, that were 64 pixels tall (that's 64 normal pixels, as opposed to the chunky pixels I'm creating).
They were moving around the screen at around 11-12 fps.
That didn't contain the final big optimisation I plan to make.

Having lots of large-ish sprites on the screen at once is looking possible.  :)

If you have ram, you could consider a z buffer like approach, but based on the tile size you are using?
Or even a dirty buffer like idea?
Then draw front to back to avoid overdraw.
I'm not sure if that would be possible for what you want to do, or if that would be suitable.

Quote from: CP/M User on 09:21, 21 December 10
The game I'm thinking of uses Colour Switching, Scrolling Backdrops and large-ish sprites which slows down a little bit when too much is on screen - some people on the scene has critised this and trash the game, but it doesn't bother me, I'm more bothered by the number of times I've completed it - and critics call it too difficult (I better not name the game otherwise I'll get branded!).

Do tell! Go on, which game is it?

Quote from: arnoldemu on 10:35, 21 December 10
If you have ram, you could consider a z buffer like approach, but based on the tile size you are using?
Or even a dirty buffer like idea?
Then draw front to back to avoid overdraw.
I'm not sure if that would be possible for what you want to do, or if that would be suitable.

A z-buffer approach... hmmm... is that where the "nearest" sprite is drawn first, and only the visible bits of the 2nd-nearest sprite are drawn, and so on and on?

As for the dirty buffer... is that when only changed parts of the screen are actually drawn?

Quote from: ervin on 13:48, 21 December 10
A z-buffer approach... hmmm... is that where the "nearest" sprite is drawn first, and only the visible bits of the 2nd-nearest sprite are drawn, and so on and on?

yes

Quote from: ervin on 13:48, 21 December 10
As for the dirty buffer... is that when only changed parts of the screen are actually drawn?

Yes, but it could also be used to tag which cells you have drawn to your screen, so you can avoid drawing them again, so perhaps a simple z buffer, but yes, also for tagging which parts of the screen have changed.

If your going for dirty buffer you can group 8 consecutive cells together into a byte to get a better speedup.

Quote from: arnoldemu on 14:00, 21 December 10
If your going for dirty buffer you can group 8 consecutive cells together into a byte to get a better speedup.

That's a good idea.
Do you mean by setting up to 8 bits to represent 8 cells?

Thanks for your great suggestions, by the way!

It's on this page (http://www.cpcgamereviews.com/w/index4.html), but it's not the Wombles!  8)

Quote from: CP/M User on 23:28, 21 December 10
It's on this page (http://www.cpcgamereviews.com/w/index4.html), but it's not the Wombles!  8)

Is it Wizard Willy?
I remember that being quite impressive, despite the slowdown.

Oh! By the way, Savage is now moving at 5.9fps.
Woohoo for progress! Still a lot to do...

ervin wrote:

Is it Wizard Willy?
I remember that being quite impressive, despite the slowdown.

Yep! And the sad thing about it is I've probably completed it Hundreds of times!  ???  The game does slow down, but if you shoot the baddies, collect the eyes and other tokens and keep moving, the game is straightfoward, towards the end of Level 3 and in Level 4 the game gets tricky cause you need to do some perfect jump timing to get the eye and avoid the instant death laterns, but if you buildup your lives, you should just get away cause there's only around 4 of them. In the game itself there's hardly any sound fx, there's the zapping sound if you zapped the baddie and the sound of you dying, the badies don't generate any sound and there's no shooting sounds when you cast a spell and the game is only accompanied by a tune on the title screen. Given it's been made in 40k or so and no multiloads, I reckon is pretty good going!  ;D

If I remember correctly it even had some pretty nice parallax scrolling.

... hang on, I'll just download it and try it ...

Ok, I'm back.
Yes indeed, very nice scrolling indeed.

Savage is now 6.25fps. Yippee!

ervin wrote:

If I remember correctly it even had some pretty nice parallax scrolling.

... hang on, I'll just download it and try it ...

Ok, I'm back.
Yes indeed, very nice scrolling indeed.

WW has some very nice graphical elements in it and the scrolling as you say is very nice. The animated components in the background I think are colour switches from the palette. The Scrolling in WW seems to be quite complicated given there's foreground objects platforms which you interact with and the background. Even the ground stands out from the background, amazing!  ;D 

Savage is now 6.25fps. Yippee!

Sounds good! :D

Woohoo! Giant Savage is now moving around at approx 10-11 fps!
I'm very chuffed, I must say.  8)

I don't think I can squeeze any more performance out of the sprite data processing code.
It has been optimised to within an inch of its life, and I've (very carefully) used the shadow registers, the 8-bit index registers, even the I register, to avoid accessing memory locations directly.
I've rearranged code so that less stuff happens to registers each frame... I'm really quite proud of it.

Now it's time to implement a dirty-buffer type of idea, where only changes to the screen are actually rendered, so to speak. That should speed things up a whole lot more, with any luck!

Do you have a target? 10-11 is not too bad, but it depends on what else is going on on the screen...

Well, I'll push it as far as I can with a few more crazy optimisation ideas.
I'm hoping to get 20fps. Or at least 17.5 fps which is what Savage the game itself seems to run at (I made a video in Winape and counted the frames!)

But it'll be quite a challenge, as this is a full mode 0 screen, not a shrunken spectrum sized one.
Also, the sprites clip to all 4 screen edges nicely (it appears to work perfectly!), and they all have transparency as well, so there are quite a few overheads. Also, the sprites can be pretty much any size, memory permitting. It's pretty flexible, and I'm trying to do it without sacrificing performance.

I remain optimistic!  8)

Quote from: ervin on 10:11, 23 December 10
I remain optimistic!  8)

Yes. Good. Keep going.

Game development is like a rollercoaster.. there are times when the coding goes well, it fits into ram, and it's working fast (it was like this for me a few weeks ago on my current project), and then there are times where it all seems to go wrong, things take much longer to code (a week back for me), but then that passes and you get through it (now), finish it and release it (next year ;) ).

In the end, if it doesn't work out fast enough, it may still be worth continuing to completion to get an idea of how the game goes together, how to package the final build, if it is a bit slow, scale back or modify your design to work with it.

I really hope it goes as fast as you want, I think it's an interesting idea to go for, and I think the way you are drawing the screen is also interesting and could open up a new route of ideas for cpc games.. where chunky is embraced as part of the game design.

Keep going and there are plenty of people who want to help, even in small ways, if you need it.

Thanks for the kind words!
I really appreciate all the help you've given me so far, and I'm sure everyone else around here would agree with that sentiment, for all the help you've offered over the years.

I do indeed remain optimistic, and I really believe that I can figure out how to do everything my game design requires.
There are a couple of things I don't know how to do yet (like using the extra 64k to store sprite data, and paging it in, and also scaling sprites), but I'll figure them out.

Indeed, I also really like the idea of chunky being used for design and performance reasons. If used correctly, it could lead to really fast games, I think.

Incidentally, don't get alarmed by "scaling sprites". It'll be done behind the scenes at level transition time, as opposed to being realtime. The idea is to have one copy of each sprite sitting in the extra 64k waiting to be called upon.
When one is needed, it will be read into normal ram, and different sizes of it will be created, ready for the next level. This should be a lot faster than disk access, and probably a lot more flexible too.

Personally, I can't wait to see the game that is running in my head, working on a cpc.
I wish I could see it on a real cpc, but WinAPE will have to do.  :)

Maybe when it is ready, someone with a real cpc can post a video of it to youtube... 8)

Yes it should work faster minus the hidden frames!  ;)

Otherwise it sounds pretty good.  :)

That's really interesting about the speed of Savage in fps - I always wondered about that.  I don't know why but I am obsessed with 50hz and am only just getting my head around the fact that I can use 25fps and use two frames worth of code every time.  8)

Your project is fascinating to hear about and as arnoldemu said, it could open up new doors.  Keep up the good work and it sounds as if you are rapidly turning into quite a programmer  :)

Quote from: redbox on 19:45, 23 December 10
That's really interesting about the speed of Savage in fps - I always wondered about that.  I don't know why but I am obsessed with 50hz and am only just getting my head around the fact that I can use 25fps and use two frames worth of code every time.  8)

Your project is fascinating to hear about and as arnoldemu said, it could open up new doors.  Keep up the good work and it sounds as if you are rapidly turning into quite a programmer  :)

Thanks man.

Yes, I hope this crazy chunky pixel idea inspires others to do something with the concept. Who knows what might pop up?

I've actually been a professional programmer for over 16 years, as a database programmer. Thrilling eh?  ::)
Game dev is MUCH more interesting. The concepts of game dev are quite simple - it's the implementation that's the tricky bit, particularly in low-level z80! It's an awesome challenge that is very rewarding, and really enjoyable.

Having said that, I'm a bit of an optimisation fanatic with databases as well.  :)
That obsessive streak comes in handy when dealing with only 4Mhz (or whatever the cpc z80 actually runs at!)

Quote from: ervin on 09:32, 28 December 10
Having said that, I'm a bit of an optimisation fanatic with databases as well.  :)

That's interesting - I recently asked someone to make a MySQL database run faster and their answer was "buy a better server"!  ::)

Alrighty, update time!

I've spent the last fortnight completely rewriting the sprite processing code.
The algorithm was rewritten from scratch, and is now much more efficient, and faster as a result.
I don't see how (with my current knowledge) I can speed it up any further.

Of course, every time I think a routine is done, I think of some other crazy idea to try!  8)

Anyway, I've also implemented two ideas for speeding up the screen drawing, and they are working really well.
They were actually much easier to implement than the sprite processing code, but the results are far more dramatic.

The first is to only draw rows that had a sprite write in them in either the previous or current frame (the screen is drawn as 50 rows of chunky pixels, so there are 50 rows to draw or ignore).
This results in a VERY large speedup when the sprite (in this case giant Savage) moves partly off the screen.
In fact the speedup might be too much, as it would cause large framerate (and game-logic-timing) fluctuations in-game.
I don't really know what to do about this... although in the game I'm planning, it may not be a problem, as the largest sprites would only appear on-screen very briefly. Not sure yet...

The second optimisation is to only draw columns that have had a sprite write to them.
I currently process the screen as 8 columns (8 groups of 10 bytes for each pixel row).
I haven't figured out the optimal number of columns groups to be using yet, but I suspect 8 groups might be about right.
Having more groups means I'd need to do more stack pointer hijinx for each pixel row, and more SET/RES stuff. More overheads in other words.
Having less groups would be very difficult now, as I had to rewrite some parts of the screen-redraw code to accomodate these 2 optimisations. I had to let go of a couple of registers in the push/pop cycle.

These optimisations came from the ashes of the unfinished rewrite of my 3d-maze conversion, where I was researching the idea of only drawing "changed" parts of the screen. They have been significantly refined since then though.

Anyway, I'm very chuffed with the results.
Please download the updated version and have a play.
It's attached to the original post in this thread.
You'll notice that as Savage moves towards any of the 4 screen edges, he speeds up a lot (particularly as there is less of him displayed vertically). As mentioned above, this may be ok for my game design.

There's one more nutty optimisation idea I'm going to try... it may be a really silly idea, and fail miserably. Or it might be awesome. I don't know yet.

After that, it'll be time to write some code that shows what sort of game this will be.  ;)

I've just discover your amazing piece of code, very very impressive.   very smooth.  maybe you can slow it down when the number of pixel is   lower than a defined amount to maintain the same velocity?

Quote from: jbaudrand on 19:16, 05 January 11
I've just discover your amazing piece of code, very very impressive.   very smooth.  maybe you can slow it down when the number of pixel is   lower than a defined amount to maintain the same velocity?

Thanks - that's a good idea.
I might try it if the game is unplayable due to framerate fluctuations.

Incidentally, I've uploaded a new version to the first post in this thread.
It contains a new (very basic) front-end, which really just lists the controls.
You can now change Savage's movement speed, anywhere from 1 pixel to 10 pixel steps.

[EDIT]

I've exhausted my optimisation ideas now.
The final idea actually slowed Savage down.  :(
Oh well...

Luckily most sprites in the game will be smaller than giant savage, so the game should run pretty quickly. Even if there are any sprites as big as our friend, it's doubtful there'll be 2 on the screen at a time, in full view (i.e. unclipped).

Onto the next phase now!

Time for another little update.

I've taken Savage out, and put Miner Willy in.
The attached file simply has a chunky willy  :laugh: on-screen.
He can be moved around with the arrow keys.

The purpose of this prototype is to show the new screen display routines.
I took out the routines that made Savage speed up so dramatically when he was partly (or mostly) off-screen.
I now have a cell-based system, where the program keeps track of which cells are written to.
I'm using a 50x8 array. 50 rows, with 8 columns.

As you move willy around, you'll see the area around him change colour, as the cells that need to be printed are drawn to screen memory. In the demo, once a cell has been written to, it will stay that colour. That's because I'm not drawing some other stuff over the top of it.

Only the cells that willy is "in" are actually printed each frame. This will (hopefully) allow my game to run quickly, and this technique should also have a more consistent framerate than my previous effort.

Move vertically, and the rows fill in smoothly. Move horizontally, and the columns fill in, in quite dramatic jumps.
Having more columns would take more memory, and there would be more overhead keeping track of it all in realtime.

Enjoy!

Hey Ervin, this is turning into a really thought provoking piece of code.

It's actually given me an idea for a demo effect that I'm working on now!

Will watch your optimisations with interest  ;)

Hi redbox.

I'm glad it's giving you some ideas - that's really cool.
I've actually thought of some more little optimisations, and it is now running a bit faster.

I'm (ab)using the stack pointer in the routine that processes sprite data now, and that routine has sped up by about 15%, which is handy. I've tried several ideas to make that routine faster, but the stack pointer idea was the only one that really provided any benefit over what I already had.

Hopefully I'll have the final version of the sprite processing and screen display routines for a demo shortly.
It's just amazing how many ways there are to skin a cat, so to speak!

Well, I'm done with the sprite processing and screen display routines.  :)
I just can't think of any more ways to make them faster.
I've tried several different algorithms and data storage techiques, and I've delved into all sorts of machine code black magic, but this is the best I'm capable of at the moment.
I'm sure some of the ace programmers around these parts could do better, but what I've been able to figure out will have to suffice.

Okay, I've attached the final "engine prototype" to this post.
In it you'll find Savage being harassed by 9 reasonably large Miner Willy sprites.

Savage can be moved around with the arrow keys, while the Willy sprites just move up and down.

All the sprites have transparency, and all of them get clipped when they reach the screen edges.
When the Savage sprite is virtually filling the screen, it's not the fastest thing around, but it is running full-screen, so I'm really happy with it.
When he goes partially off-screen, it speeds up and gets accordingly smoother.

In any case, it's fine for my game design, and now I'll finally be able to start concentrating on that.

This phase of optimisation is now OVER!
8)

This is great!

/ygdrazil

Quote from: ervin on 01:23, 17 January 11
Well, I'm done with the sprite processing and screen display routines.  :)
I just can't think of any more ways to make them faster.
I've tried several different algorithms and data storage techiques, and I've delved into all sorts of machine code black magic, but this is the best I'm capable of at the moment.
I'm sure some of the ace programmers around these parts could do better, but what I've been able to figure out will have to suffice.

Okay, I've attached the final "engine prototype" to this post.
In it you'll find Savage being harassed by 9 reasonably large Miner Willy sprites.

Savage can be moved around with the arrow keys, while the Willy sprites just move up and down.

All the sprites have transparency, and all of them get clipped when they reach the screen edges.
When the Savage sprite is virtually filling the screen, it's not the fastest thing around, but it is running full-screen, so I'm really happy with it.
When he goes partially off-screen, it speeds up and gets accordingly smoother.

In any case, it's fine for my game design, and now I'll finally be able to start concentrating on that.

This phase of optimisation is now OVER!
8)

Quote from: ervin on 01:23, 17 January 11
In any case, it's fine for my game design, and now I'll finally be able to start concentrating on that.

Really cool, liking what you're doing.  :)

Moves along at an impressive speed given how much data you're shifting.

Thanks guys.

Now I'm trying to figure out how to dynamically create and destroy sprite entities at runtime.
???

I can do it in something like Blitz3D on the PC with my arms tied behind my back, but for the cpc, it's a very different kettle of fish!

Never let it be said that the IX and IY registers are useless in high speed games!

For the last couple of weeks, while working on other parts of my game, the screen rendering routine has been nagging away at the back of my brain. I just knew that it could be made faster, but I couldn't figure out how.

Well, after staring at the routine for literally hours, I decided to try changing the way the registers in that routine are used.

I shuffled them around, gave them different tasks etc. And I found a combination that used the IX and IY registers in such a way as to free up the BC and DE register pairs and allow them to be used more effectively.

For example, IX is pointing to the start of a block of memory that determines whether or not a particular part of the screen should be rendered in a screen refresh, and I can do this:

srl (ix+n),a
rra
jr nc,NEXT_CELL

That, along with a couple of other changes using the IY register and a few other little things, has led to the screen refresh routine becoming over 10% faster!

VERY CHUFFED I AM!

Quote from: ervin on 03:06, 03 February 11
Never let it be said that the IX and IY registers are useless in high speed games!

I have found this too, although I do not use them of my first choice because of their speed.  But you're right, they can be very effectively used to speed something up!

Well done with your optimisation.  :)

Quote from: ervin on 03:06, 03 February 11
Never let it be said that the IX and IY registers are useless in high speed games!

Heh, well OK not useless, but they're certainly a last resort in my mind!  ;)


Still, faster code is always satisfying to work out, and I'd have to admit there's been times when I've found the gymnastics required to use alternate registers or faff about with things on the stack turns out to be slower than using those accursedly slow index registers!  ;D

Indeed, I usually leave them as a last resort as well.

I'm actually surprised at how effective they have been in this case!
8)

I don't understand a bit about the above, but GREAT JOB! :D Let's see it put in use...

I hope to have something cool to show off soon, once I figure out how to do a 3D road!
(It's not a racing game, by the way).

It's got a road, it's a racer, no matter if you use a supersized bunny shooting up Dobkeratopses! :D

Heck, that's an idea worth thinking about!
:laugh:

If only I could program...

Give it a go. You might really like it.
Even creating something simple to start with can be really satisfying.

Programming is a difficult hobby, but also very rewarding.  8)

Only problem is that it is also very time-consuming!

Gryzor wrote:

If only I could program...

Never too late to learn if one is interested! Or even if the family want to have a go!  :)

The problem is sourcing out good programming examples, and sometimes finding the right programming language also matters, so BASIC isn't necessarily a computer language for everyone. I thought I read from someone somewhere how they hated BASIC and couldn't understand it and then turn around and talked about how they Loved their "C" based language!  :-[  BASIC has the problem of being too restricted to what a Magazine publisher demands which would be along the lines of Spaghetti Programming. You can write good structured code in BASIC and I just saw an example of a game in one of my magazines the other day clearly high lighting how the program works!  ;D  Shoot the "GOTO" man!  >:(

Yeah... thanks for the encouraging words mates, but not gonna happen :( Over the years I've tried learning some stuff and have even put together a few small programs to help me with my work, but learning to program requires dedication and time - and I don't have the time to give it the dedication it needs! Too many hobbies to pick up such a serious one :( Oh well, back to knitting...

Quote from: ervin on 10:06, 07 February 11
Programming is a difficult hobby, but also very rewarding.  8)

Especially with the Z80.  :D

But optimising a routine down to something mega quick (which is pretty much essential with only 4Mhz of love) is totally what it's all about.  :)

Quote from: redbox on 19:26, 07 February 11
optimising a routine down to something mega quick (which is pretty much essential with only 4Mhz of love) is totally what it's all about.  :)

Amen, brother!
You're absolutely right - squeezing that extra frame per second is quite the challenge, and a damn satisfying one!

Quote from: Gryzor on 19:02, 07 February 11
Yeah... thanks for the encouraging words mates, but not gonna happen :( Over the years I've tried learning some stuff and have even put together a few small programs to help me with my work, but learning to program requires dedication and time - and I don't have the time to give it the dedication it needs! Too many hobbies to pick up such a serious one :( Oh well, back to knitting...

Well I am sure you have the skills in other ways? game design? pixelling? music?
level design?

Quote from: arnoldemu on 10:33, 08 February 11
Well I am sure you have the skills in other ways? game design? pixelling? music?
level design?

Exactly! Loading/splash screens, tiles etc. There are lots of little bits out there. I always wanted to be able to program but decided that it's better for me to work on other areas and leave those "Input error in line 10" to someone else ;D

Gryzor wrote:

"Too many hobbies to pick up such a serious one" :(

Too right, nothing compares it to generating some Sprites and Music eh Maestro?  ;)

Quote from: arnoldemu on 10:33, 08 February 11
Well I am sure you have the skills in other ways? game design? pixelling? music?
level design?

Ahhh no. I'm not the creative guy, I'm afraid. I'm good at my job (marketing) because I can manage things and supervise the creative processes, but I'm no good in them myself (even if, in the past, I have been known to produce some gfx to replace crappy 'professional' ones for online campaigns. But that was the designer's fault :D ).

You could be like the 21st Century guy representing AMSOFT, marketing CPC Software and flogging off Amstrad Emulators!  ;)

464 Posts!  :-[

Quote from: Gryzor on 09:46, 11 February 11
Ahhh no. I'm not the creative guy, I'm afraid. I'm good at my job (marketing) because I can manage things and supervise the creative processes, but I'm no good in them myself (even if, in the past, I have been known to produce some gfx to replace crappy 'professional' ones for online campaigns. But that was the designer's fault :D ).

market the wiki, or perhaps market the new cpc games?
;)

Wow! I loved reading this thread from the beginning till this point.
First of all the very constructive programming discussion. The improvement, the impressive examples.
I also see some new coders on the CPC working on projects with a good spirit for optimize and experimentation.
I wouldn't have discovered these attempts if I kept reading some other CPC forums only. I guess it would be nice to visit more frequently cpcwiki forum :)


Now that would be a very nice engine for space harrier style game. With so many zoomed big sprites I wouldn't mind even if this game was running at 6fps. It would still be impressive. About the precalced zooming sprites it's a good idea. Because the graphics screen is of bigger pixels one could store few different zooming levels of the same sprite in much less memory used. It's a good idea and the realtime zoom would be much slower. I was thinking about this and I think I had seen some example C64 preview game with zooming fullscreen sprites like this but I can't find it (it wasn't a known one but it impressed me at the time).


Every trick here is nice, starting with the classic use of PUSH and POP to write/read data fast, SET/RES techniques to move to next line (a trick I haven't considered before (my mistake), but proved great in my recent wolfenstein wall column rendering engine, oh I also jump to arbitary line so that I only do one SET or RES per line at best) and the technique to split in 8 blocks is marvelous. Definitelly this thread is a nice set of ideas if I want to make something similar in the future or for any other sprite ideas.


Good luck with the rest of the project. I'll be watching the wikiforums more frequently I think.

Thanks for the kind words Optimus!
I was VERY impressed by your raycasting engine, by the way.

It will indeed be a Space Harrier style game, at least in the game's viewpoint.
But it won't be a shooter.

At the moment I'm struggling with creating a 3d road.
I'm getting there, bit by bit, but as with everything coded so far, I'm stumbling across ideas and tricks along the way, and that takes a bit of time.  :(

But if I can replicate the 3d road in my brain into something on the cpc, I reckon it'll look pretty cool.
Then it'll be time to see if my theories about the scaled sprites will work...

Regarding the c64 game, I wonder if you could have been thinking of something by Chris Butler.
His work was phenomenal. Space Harrier, Thunderblade, the magnificent Powerdrift and of course Turbo Charge.
He was a bit of a genius.

This is an interesting article about his work:
http://www.mayhem64.co.uk/butler.htm (http://www.mayhem64.co.uk/butler.htm)

His amazing work with the c64 has been one of the main inspirations behind my little project.  8)

[EDIT] I think I may have figured out a very efficient technique for a 3d road! With hills! I'm very excited by it, as it seems very doable. No code yet, as I'm still thinking through the technique.

Anyone else often solve programming problems in the shower, or while stuck in traffic?

Woohoo! Something worth reporting!

I've been working on a hill algorithm since my last post, and it has been really difficult.  :(
I've been through a number of ideas and algorithms, and I've finally found one which works.  8)

At the moment it only exists in a side-view scrolling line, representing each "piece" of road that will eventually be drawn in the familiary into-the-screen style. It has allowed me to mess with hills and also with the tilting of the view, in order to get a feel for how it should all fit together. The road pieces also change colour, to simulate the colour cycling that was common for 3d roads back in the day.

It's all data-driven, which means it should be fairly easy to generate roads in-game (well, at the start of a level), when I get to that stage. Hopefully soon...

Even in it's current unoptimised state, it runs quickly, so I have high hopes for a very efficient 3d road routine.

I would just love to see this in action.

Do you mean the road hills prototype?
Or the 3D road?

I can show you the prototype once I fix a little bug, but the 3D road will take a bit longer.  :-[
(It ain't pretty though... it is purely functional)!

Any of those would be great to see just to get an idea of how well it's working and whats achievable.

Alrighty, hopefully I have something presentable very soon!  :) 

Quote from: ervin on 10:33, 26 February 11
Alrighty, hopefully I have something presentable very soon!  :)

Yay, am really looking forward to this.

Man, this 3d road thing is driving me nuts!
I'm probably being too ambitious, but I have a vision in my head that I want to see through to fruition.
I will keep going until I figure it out!

Crossing fingers... I guess we're all behind you :)

Quote from: ervin on 15:41, 13 March 11
Man, this 3d road thing is driving me nuts!
I'm probably being too ambitious, but I have a vision in my head that I want to see through to fruition.
I will keep going until I figure it out!

Sending you positive programming energy.

Quote from: sigh on 00:19, 14 March 11
Sending you positive programming energy.

Me too!  :)

 :) Thanks everyone.

Alrighty!

It looks like all that positive energy worked, because I think I've FINALLY figured out a good method for creating a road on the fly!

Once again, the idea came to me when I was away from the keyboard. Funny how that sort of thing happens.

I have 13 different road segment designs, and they can be combined in all sorts of ways to create a road with all sorts of heaving and lurching going on.

Please be aware that this is not a 3D road yet - it is simply a side-on view representing the data flowing through the "road queue". That data will be converted into a 3D road soon, with any luck.

I also need to implement view tilting, which will be represented in the 2D view as the relevant bits of road moving up and down.

If you're wondering why only the centre of the screen is being drawn to, it's because my road will be comprised of 30 segments going off into the distance, and the 2D view displays 30 chunky pixels.

If you want to see the 2D view in action, please load up the attached cpc4.dsk in your emulator of choice, and RUN"CPCROAD"

You'll be able to choose which of the 13 segments to view; simply type in a number from 0 to 12 and press Enter. The road segment will then be created and shown to you. Entering 0 will give you a flat road segment.

Segments have a variable length, calculated randomly (with some bounds placed on them).

Also, the hills/dips have random steepness (there are 15 different steepnesses (is that a real word?) for the program to choose from). The result is a very dynamic road.

When I finally get to put it in the game, I'll probably have to limit the severity of hills/dips during the earlier levels, and ramp it up (pardon the pun) on higher levels.

Now, I'll get back to work on the tilting routines!

Wow. Lines. Lines are good. I love lines.

Just kidding :D

Hahahaha.  :laugh:

In time, these lines will develop into a fully operational battle station!

No, hang on, that's not right.

They will develop into a 3D space laneway thingy!
Yes indeed.

 ;D  I'm sure they do! And what we see now is already amazing! I like it! ;D

I think I can just about see how you're going to do this...  ;)

Quote from: redbox on 11:36, 31 March 11
I think I can just about see how you're going to do this...  ;)

Ooh! Do tell!
I'm interested to know what you are thinking.

Incidentally, I've got the tilting working to some extent now, but there are still errors.  :'(

That was very interesting (and smooth). I'm looking forward to seeing the 3D version as it's hard to picture at the moment.

Anymore progress on this?

Hi there.

Yes indeed, progress continues, with work being done on it almost every day.

The road code needed to be totally rewritten, as it was wrong, quite frankly.
No matter what I did, I couldn't figure out how to make the view "tilt" when going up or down hills.
After studying HEAPS of videos of old racing games (Outrun, Lotus, Chase HQ etc etc etc...) it finally dawned on me that I don't need to tilt the view, as none of those games did. It was all an illusion!

So I completely rewrote the code, and now it works beautifully, creating a random road in real-time, from about a dozen segment types. I've begun work on displaying it in 3D, but there's still much to do. The road stripes are working nicely though.  :)

I've also taken a detour to revisit the giant Savage sprite.
I'm not happy with the amount of memory he takes up, so I'm working on a version of him that stores colour data in a much more efficient format, but of course this requires a rewrite of the sprite processing code.  :o

I looked at messing with the CRTC to repeat 4 pixel lines for my fat pixels, instead of doing them in software.
But I just couldn't figure out how to make it work in a real-time game, where the amount of time or clock cycles between each frame can vary dramatically. So I had to shelve that idea.  :(

Getting the road to look like it's tilting isn't very difficult. The normal "triangle" road that's usually used to give the 3D effect has straight sides. Curving the two lines inwards gives the road an uphill or downhill curvature and bulging the lines outwards will give the effect of going over the cresent of the hill. Not sure how you'd achieve this in software (not my strong point), but maybe a variable could be used to determine the amount of curvature in your drawing routine, with a table of values to define the inclination for each part of the course?

Below is my badly drawn example, showing 1) straight road, 2) Road curving up or down 3) Cresent of hill. (Yup, I can't draw either :) )

Bryce.

OUT &BC00,9:OUT &BD00,3
OUT &BC00,0:OUT &BD00,127

it may not work on all monitors, modulators etc
but it can give an 8k screen
problem: every other line is border colour

but it's a crazy idea and may help?

you asked for crazy ideas?

Thanks for the tips/ideas Bryce and Kev.
Any ideas are worth considering!

But (and not many games did that) the game should adjust the speed of the car depending on the curvature of the sides. Slower=going up, faster=going down.

You need more horsepower Gryzor :D Real race cars barely slow down uphill :)

Bryce.

Quote from: Gryzor on 03:50, 10 May 11
But (and not many games did that) the game should adjust the speed of the car depending on the curvature of the sides. Slower=going up, faster=going down.

Indeed that would be worth considering... if I was actually creating a racing game.  ;)

Ahem :) Well, all sorts of vehicles and being slow down when they go up!

Quote from: Bryce on 04:26, 10 May 11
You need more horsepower Gryzor :D Real race cars barely slow down uphill :)

Bryce.

Yes, right! And if I take a look here at real traffic, then I see: People speed up when they drive up a bridge and slow a bit down when driving down. Probably this is due to the fact that the NOPD never checks speeding up on bridges  :)

Alrighty, I've completely re-written the sprite routines now.  :o
Thanks to arnoldemu, redbox and Axelay for their ideas with the sprite data format.
Savage now takes us much less memory, though I don't know the exact amount.

In addition to their ideas, I also changed the way a sprite is constructed.
For example, instead of giant Savage being a single block of data, he is now constructed of vertical strips.
Because the amount of x-axis movement is fixed depending on how "close" a sprite is to the player (in "3D"), that amount of movement can be the width for each vertical strip.

This is useful because it means that horizontal clipping is now trivial, and very cheap in cpu terms.
Vertical clipping still needs to be calculated the same way as before, but that was always quite easy and cheap, so no dramas there.

I've also realised that using vertical strips may have resulted in a rather nice side effect.
I might be able to implement sprite flipping, using the same data tables.
2 sprites for the price of 1.  :D
Savage is stored as right-facing, but with this idea he can change between left and right-facing with a toggle (once the sprite flipping code works correctly).

Once I've got sprite flipping working (fingers crossed), I'll upload a version for you all to have a play with, if you're interested.

At the moment, it's very slow, as it is completely unoptimised.
We're talking 5 frames a second here.

But that will change. Oh yes, yes it will.

Quote from: ervin on 03:25, 10 June 11
I've also realised that using vertical strips may have resulted in a rather nice side effect.
I might be able to implement sprite flipping, using the same data tables.
2 sprites for the price of 1.  :D

It did cross my mind when discussing the compression that it might be possible to store it in a different format to just plain linear.


Glad to hear you've worked out something suitable and it has extra benefits!

Hi all.

Just a little update - I'm kinda excited by this one!

Giant Savage now takes up 1,543 bytes in memory.
In his entirety.  8)

This includes 15 magnifications of him in both left and right-facing versions!
To say I'm chuffed is an understatement!

It's still a bit slow, as I've been writing the code in ccz80 (which is a lot like C), but I will start converting it to pure assembly shortly. Despite the amount of data being moved around, it runs remarkably well in the plain ccz80 version. It's a really great compiler and I'd be stuffed without it.

Incidentally, the 15 magnifications are achieved using real-time sprite scaling.
I thought of the technique while having a shower a few days ago (that sounds really bad, dunnit?!?!), and thought I'd give it a go. And it works!

Of course the z80 is too slow to do sprite scaling using any sort of maths, so I'm using scaling matrices, which tell the program which rows/columns to skip, depending on the current sprite zoom level.

It's all tremendously exciting!
;D

Quote from: ervin on 08:14, 23 June 11
Of course the z80 is too slow to do sprite scaling using any sort of maths, so I'm using scaling matrices, which tell the program which rows/columns to skip, depending on the current sprite zoom level.

Ooh yeah, nice idea!


Looking forward to seeing it.

Quote from: ervin on 08:14, 23 June 11

Of course the z80 is too slow to do sprite scaling using any sort of maths, so I'm using scaling matrices, which tell the program which rows/columns to skip, depending on the current sprite zoom level.

Are you using fixed point to do this?
I would store xincrement as fixed point 8:8, you can then add the increment easily, and then extract the high byte using ld a,h for example.

You should actually be doing a dev log with an ETA or something (which of course would slip, but you get the idea)... :)

Quote from: arnoldemu on 09:26, 23 June 11
Are you using fixed point to do this?
I would store xincrement as fixed point 8:8, you can then add the increment easily, and then extract the high byte using ld a,h for example.

I'm actually storing the scaling matrices in bit-packed data tables.
4 pixels worth of yes/no in one byte.

Technically of course I could do 8, but that wouldn't be compatible with the rest of the sprite algorithm.

Quote from: Gryzor on 14:09, 23 June 11
You should actually be doing a dev log with an ETA or something (which of course would slip, but you get the idea)... :)

Indeed I should, but I'm very much the sort of person that would get very slack with keeping the log up to date!  ;D

An ETA is hard to come by, as this dev process is very organic, and I don't have all the details of the game nailed down just yet.
(2 weeks ago, I almost changed my mind about exactly what these sprite routines should become. Luckily I came to my senses).

Quote from: ervin on 14:19, 23 June 11
Indeed I should, but I'm very much the sort of person that would get very slack with keeping the log up to date!  ;D

An ETA is hard to come by, as this dev process is very organic, and I don't have all the details of the game nailed down just yet.
(2 weeks ago, I almost changed my mind about exactly what these sprite routines should become. Luckily I came to my senses).

A dev diary would be nice for others, but I think concentrating on the game, as you are doing, is the most important thing.

Of course the program itself is more important. I just thought it'd be very fun and interesting to read about it in more detail. Dev logs as they appeared in the old magazines were truly great...

Time to demonstrate some stuff.

cpc5.dsk (attached) contains a program called JUNE2011.BAS.
Run it and you'll be able to have a play with the current version of my sprite scaling/flipping routines.

Note that the arrow keys move the camera, as opposed to moving Savage.
That's why at first he might seem to move in the opposite directions to your keypresses.

Also, the scaling factor might be a bit severe the way it is right now, but that's easy enough to change.

It is very slow at the moment, but will speed up significantly very soon.
But first, I'll have to put a large mode 1 sprite in, to keep Savage company...

I hope you all enjoy it.

Nice effect  :)   Reminds me of Sega's 'super scaler' games.

Quote from: Axelay on 07:11, 25 June 11
Nice effect  :)   Reminds me of Sega's 'super scaler' games.

Yes indeed, Outrun and (in particular) Space Harrier have been major influences and inspirations.
I'm looking forward to seeing how my routines turn out after I optimise the living heck out of them!  :D

Very nice.


Can't remember if it's been mentioned before, but have you thought about using a 32x32 character screen? 


Then you can always use 8-bit increments rather than 16-bit, which of course makes things faster.

Quote from: redbox on 13:46, 27 June 11
Very nice.

Can't remember if it's been mentioned before, but have you thought about using a 32x32 character screen? 

Then you can always use 8-bit increments rather than 16-bit, which of course makes things faster.

I haven't considered a 32x32 screen.
How much memory would such a screen take up?

Quote from: ervin on 14:18, 27 June 11
I haven't considered a 32x32 screen.
How much memory would such a screen take up?

It uses 16kb like a normal screen (well, almost - a normal screen has a few bytes free at the end and this one doesn't).


The benefit is that no pixel row crosses the 256 byte page boundry if your screen is at a normal address like &4000 or &C000.  Therefore, when moving to the next byte in a sprite routine you can always use the 8-bit INC H or INC L instead of the 16-bit INC HL, which of course is much faster especially if you're using a lot of them.


The only real thing you'd need to change in your routine is the screen width is &40 instead of the normal &50.  The next pixel line down is still &800 away so that doesn't need to be changed and you can still use SET 3,H optimisations etc.




org &8000


ld bc,&bc01 ;CRTC register 1
out (c),c
ld bc,&bd00+32 ;set width in characters
out (c),c


ld bc,&bc02 ;CRTC register 2
out (c),c
ld bc,&bd00+42 ;set horizontal position
out (c),c


ld bc,&bc06 ;CRTC register 6
out (c),c
ld bc,&bd00+32 ;set height in characters
out (c),c


ld bc,&bc07 ;CRTC regsiter 7
out (c),c
ld bc,&bd00+34 ;set vertical position
out (c),c


ret


Ah, I see. That all makes perfect sense - thanks.
However, I'm still using about a million PUSHes to draw the screen, so I probably wouldn't get any benefit from this idea.

Quote from: ervin on 15:23, 27 June 11
However, I'm still using about a million PUSHes to draw the screen, so I probably wouldn't get any benefit from this idea.

Yeah, I remembered you're using the stack after I made the post, d'oh!  :-[

Anyway, might be worth bearing in mind if you do fall back onto 'traditional' sprite routines for something else like background tiles or something.

Let us know how you get on with your new optimisations.

Quote from: redbox on 16:11, 27 June 11
Let us know how you get on with your new optimisations.

Will do.

I now have another large sprite next to Savage. A "mode 1" sprite.
I've also written a program (on PC) to quickly and accurately calculate my scaling matrices.
I'm now using 30 (instead of 15) scaling levels, so the zooming in/out on a sprite should be a lot smoother.
The scaling matrices take up quite a bit of memory, but I've got 2 ideas to shrink their RAM consumption siginificantly.

I'll put up another version shortly, and then the optimisation will begin!
:D

@ervin: Great as always.
It is good to see your progress, and I think everyone is excited to see what the future brings for your game.

Quote from: arnoldemu on 09:28, 28 June 11
@ervin: Great as always.
It is good to see your progress, and I think everyone is excited to see what the future brings for your game.

Thanks Kev.
Coming from you, that's high praise indeed.

Update time!

This version adds a second bloke to the screen, along with a bit of slowdown.
However, optimisation has not yet begun. It'll be heaps faster very soon.  :(

The 2nd bloke (I won't say who he is) is from a mode 1 game, so his sprite routine needed a few subtle changes.
My "engine" can handle mode 1 and mode 0 sprites. Mode 2 sprites won't get a look-in. I'm sure no one will have a problem with this.  :)

I've also managed to make sprite memory usage more efficient.
All the scaling matrices are now stored in arrays with 29 rows.
Each row contains x columns (ie. x bytes).

Each byte contains information for 8 pixels - ie. whether or not 8 pixels should be skipped or displayed during scaling. I learned about byte-packing recently, and the technique has come in very handy indeed.

For example, Savage's entire sprite scaling matrix takes up 29*7=203 bytes.
So in the end, I've now got Savage in my program, facing left and right, with 30 scaling levels (29 scaled, 1 unscaled) only taking up 899 bytes.

If you're interested, load up the attached dsk file and have a look.
I hope you enjoy it.

Hahaha! The second character is totally random :D (for some reason I used to like the game, even though I didn't get anywhere with it).

So when is this starting to be the next megagame? ;)

Quote from: Gryzor on 18:57, 10 July 11
Hahaha! The second character is totally random :D (for some reason I used to like the game, even though I didn't get anywhere with it).

So when is this starting to be the next megagame? ;)

Yes, Cuchulainn was the biggest mode 1 sprite I could think of at the time (along with John Marsh from Marsport of course), so he had to be the one.

It's interesting, as I was typing this reply, I decided to find out (after all these years) how to pronounce the name.
Luckily there's a "Listen" link on the wikipedia page about him.
http://en.wikipedia.org/wiki/C%C3%BA_Chulainn (http://en.wikipedia.org/wiki/C%C3%BA_Chulainn)

The character himself is very interesting as well. I dunno why it took me this long to look into it!
(Carter and Follis would raise a collective eyebrow - I used to think Cuchulainn was a Scottish hero - he's actually Irish).

Next megagame? I hope so!
The optimisation of the sprite routines is coming along nicely.
Sprite scaling inconsistencies between flipped/unflipped sprites have been addressed, and sprite clipping has been sped up a lot as well.

Once I'm happy with the sprite routines, I'll get back into the 3D road!  8)

Hmmm, ask anyone who's Irish, we had all that Cú Chulainn / Táin Bó Cúailnge / Tír na nÒg shite beaten into us in primary school. A seriously boring pain in the arse if you ask me, but at least it was better than Peig Sayers :D (Only Irish people will have even the slightest idea what I'm talking about).

Bryce.

Quote from: Bryce on 10:49, 11 July 11but at least it was better than Peig Sayers :D (Only Irish people will have even the slightest idea what I'm talking about).

I can imagine quite clearly what you meant: http://en.wikipedia.org/wiki/Peig_Sayers (http://en.wikipedia.org/wiki/Peig_Sayers)

Why bash your mythology? Granted, the wikipedia articles are too long and it's too hot for me to digest them, but usually mythologies are really fascinating (I should say so, my gal is a greek mythology buff).

I'm not bashing the Mythology, rather the way it was taught to us in school  ::)

Bryce.

Seriously, how badly can mythology be taught at school? History, sure, I've seen it butchered again and again, but mythology is a collection of fairy tales for chrissakes!

Not where I come from. Here they tend to blur the lines and teach it to you like history, having to learn every detail and relationship between characters in the end you're not sure what's real and what's not. It's also not as interesting as Greek Mythology, due to the fact that it doesn't include Gods that whack you with bolts of lightening or the Sea dwelling, Fork holding types either. In fact Cú chulainns claim-to-fame was killing some blokes dog (Culainn) and then offering to be that blokes dog as a replacement (Cú Culainn = Culainns Hound).

Peig (or Pig as we called it) is an endlessly long monotonous lifestory of a depressed woman living on a poverty-stricken baren island with crap weather, where absolutely nothing ever happens, recalling in mind-numbing detail every coma-inducing, boring detail of her fruitless existance. On top of that, you're not allowed read it in English, only in Irish. but that's just my (and most 70's/80's Irish pupils) opinion, but don't take my word for it, grab a copy and let me know what you think :D It's a real chuckle.

Bryce.

Quote from: Gryzor on 15:57, 11 July 11
Why bash your mythology? Granted, the wikipedia articles are too long and it's too hot for me to digest them, but usually mythologies are really fascinating (I should say so, my gal is a greek mythology buff).

LOVE Greek mythology. I've been into it since I was a young boy.
My all-time favourite is the story of Perseus.
As a result, I found the recent "de-make" of Clash of the Titans tremendously hurtful!  >:(

You watched that? The shame's on you :D

Wish someone did a tv-series about Greek mythology - it's a proper soap-opera, only with lots more blood and sex -, in the style of Spartacus/Gods of the Arena. That would be something.

@Bryce: I should really check these stories out; if nothing else, because I bet there's something deeper in there. Taking the place of a dog sounds very disturbed in a Freudian sense. Not all mythology has to feature guts and glory, after all (though it is of course better material for statues and temples and all).

Interesting trivia: depending on which myth you draw from, Zeus had a few dozens of children, of course most of them illegitimate. Now *that's* life.

Quote from: Gryzor on 06:47, 12 July 11
You watched that? The shame's on you :D

Yes, when I first saw the trailer, I was jumping out of my skin with excitement.
I loved the original Clash (starring a big-haired Harry Hamlin), and I thought a modern version with CGI monsters would be excellent.

How wrong I was...  :'(

I believe Sam Worthington actually apologised for his appalling performance as Perseus.
PLANKseus, more like!

To give it some credit though, the Medusa scene was FANTASTIC.
Pity everything else in it was utter tripe.

I only liked the Medusa Scene, Hades (specially at the end of the film when he appears in the middle of the air and show the black, smokey wings), and Gods' armors.


The rest is totally bullshit.


For god's sake! I have the DVD of the original film sing by Ray Harryhausem himself! The new film almost made cry, what a horrible movie...

I thought the idea of Hades as an evil character was ridiculous. That just didn't match with the mythology at all.

Serious?!?!?! Signed by Harryhausen himself?!?!?!
:o 8)
Awesome!

Yep, and Jason and the Argonauts too!  8)


He came some years ago to the Comic Con in Barcelona and I had the chance to get my movies signed.


Even feeling not so well and coming in in a wheelchair, he was pretty charming with everybody and showed us a big smile.


Nice to see more people here that like classic movies, but that's for an off-topic thread, hehe  ;D

Update time.

So close...
I'm really close to releasing what I hope will be the final version of the sprite code.

I've managed to combine all the different combinations of sprite manipulation requirements into one super-complex routine. Mode 0 sprites, mode 1 sprites, flipped, un-flipped, scaled, un-scaled. Fantastic. And it takes up much less memory than the version I had before which had the different options as separate (albeit much smaller) routines.

To make it work, I'm not using slow comparison operators inside of the big evil loop.
Nope, I'm using insane amounts of self-modifying code, performed once per sprite per frame.
This keeps the speed up, but makes the code a lot harder to read of course.
And the speed is indeed very nice now. The scaling looks great in action, and I'm looking forward to showing you all.

Anyway, this morning I had just one little bug left to fix.
When a scaled sprite was being clipped to the left side of the screen, the scaling became a bit distorted.
I sorted that out and tried it with Savage. Beautiful. Worked perfectly.

Then I tried it with Cuchulainn.

And he promptly became a dwarf.

AAAARRRRRGGGGHHHH!!!!  >:(

He was working correctly last night.
I don't know what I've done to upset him.

I'll fix him though... yes, yes I will.

[EDIT] ... and with that, he's fixed.
It's amazing what a little walk, thinking about something unrelated, can do for your programming.
The solution popped in to my head, and I had to rush back and put it in.

And voila, here it is.
I hope you enjoy it.

Now this time, I will finally move on to development of the 3D road!  ;)

That is seriously good.


Well done!  :)

Quote from: redbox on 10:51, 28 July 11
That is seriously good.

Well done!  :)

Thanks man. I'm very excited about the direction it is heading in!

Great work!


Let's see what comes next  ;)

Hi all.

So far this project hasn't needed any sort of sprite masking, but the need to use it has reared its head.
The problem with this is that I had no idea how to do masking.

After much research, and head-scratching, I finally figured it out, and managed to throw together a little test program that masks a vertical line against all 16 inks in mode 0.

It was surprisingly tricky to work out, but I'm very happy with the result, and I'll be able to use my findings in my game now.  :)

If you're interested in checking out the test program, download the attached dsk.

It may help you do define two datasets for every sprite:

1. dataset: The mask. You AND it with the V-RAM data to mask out pixel.

2. dataset: The sprite data. You OR it with the previously masked V-RAM data, to set sprite pixel.

AND and OR only take one ys and if you use the second register set, you can create a real quick sprite routine.

I had toyed with the idea of using a second dataset for my sprite masks, but unfortunately some of my sprites are very large. The eternal battle between speed and memory usage continues!  :)

I had to resort to using a lookup table for pixel masks.
It seems to be pretty quick. Once I have some big sprites moving around I'll have a better idea of whether or not the speed is good enough.  8)

Actually speed depends a lot on the question if you use scrolling or not. And also: Overscan or not.

No scrolling in my game, and no overscan.

To keep the speed up, I'm only updating the parts of the screen that need to change each frame.
That helps a lot.

Any speed problems will be as a result of the huge sprites I'm using!  :)

If you are not scrolling, then you can use giant sprites ;-)

May you like to consider to switch to 32 * 32 (in Mode 1 characters) screen resolution, it make the mathematics more easy.

Hi all.

Wow - has it really been 9 months since the last update?!?!?!
Holy cow...

Alrighty, work has (believe it or not) continued on this project.
I did have a quiet few months at the end of 2011, due to RealLife(tm).
But of course that itch is always in the back of a programmer's mind...

When I got my recent CPC6128 acquisition working, I was able to finally run my code on real hardware.
It was a wonderful, inspiring, and very proud moment, and the creative spark returned.  :)

I did a whole lot of work on the road routines, and then got stuck for several weeks trying to figure out how to translate it to pseudo-3D.  :-[

Then 2 nights ago, while laying in bed ready to go to sleep, an idea popped into my brain. I quietly crept out of bed so as to not wake my lovely wife, and got to work.

I now have a routine (on PC) that calculates raster positions (i.e. y coordinate) depending on an object's Z coordinate. These coordinates will be stored in a lookup table.

I had initially toyed with figures from actual perspective projections, and of course it looked realistic, but it just didn't feel "right" in the content of my game. I studied videos of Outrun, Space Harrier etc. etc. and realised that the sprite scaling calculations don't appear to be accurate  anyway! They have been scaled in order to create an illusion of movement and speed, rather than an illusion of 3D! (I could be wrong about this of course!)

Anyway, the routine I have now matches more closely the way those Sega games scaled their sprites.

In the last few weeks, I've also thrown away the scaling matrix lookup tables, which would have required quite a large amount of memory. Every width had to have its own scaling matrix (eg. the matrix for a 64-pixel wide sprite, for all scaling levels).

Instead I'm now calculating the scaling matrix for a sprite, once per frame, in real-time. It took several failed attempts, but I finally came up with a scaling routine that I was very happy with.

It is of course a little bit slower than simply looking up the scaling matrix, but it uses a heck of a lot less memory!
In fact the routine is very small, and in real usage (i.e. how fast the routine "feels"), there is no noticeable difference.
If I remember correctly, it takes just over half a second longer to render a screen-height sprite 100 times. I think that is an acceptable trade-off between speed and memory.  8)

Another benefit is that I can plug in new sprites much more easily now, as I don't need to go through the tedious process of pre-calculating the required scaling matrices.

So I now have a way to quickly determine the raster that a sprite should be sitting on, and which raster each strip of "road" should be allocated to. I've also got sprite scaling routines that I am very happy with, from both speed and "visual feel" terms.

Now to get something useful working!

Incidentally, a couple of weeks ago, I had almost committed to abandoning the idea of a 3D undulating road.
But now that idea is back, and hopefully I'll be able to implement it.

Thanks for the update, really nice to see things are progressing and that that CPC of yours is going to be put to good use :)


Btw, I always keep a notepad at my bedside :)

Quote from: Gryzor on 18:54, 04 June 12
Btw, I always keep a notepad at my bedside :)

Indeed the notepad would be the way to go... but I just couldn't let the idea wait.  8)
Tsk. Developers eh?

Alrighty, we have a working road now.
At last.

It doesn't undulate, or even bend or twist, but it does work.
Slowly.

It is frightfully slow at the moment, due to being completely unoptimised.
It's going to be a heck of a lot faster than this - I'm certain of it.

Well, with Winape in turbo mode it's fast....ish. Good job :)

 :laugh:

I'm actually using WinAPE's turbo mode to make testing bearable during this unoptimised phase.
Incidentally, I've already got it running quite a bit faster - and looking a bit different as well.

I've got the road code looking very different, and also running a heck of a lot faster now.
There is still lots more optimisation to do though, which is good as I ultimately want the road itself to have a negligible effect on framerate. The sprites will need as much cpu time as they can get.  8)

I also found a few bugs related to the way the road works depending on how fast the "player" is travelling. I think it is all ok now.

When the attached program loads, you'll be presented with 3 options: slow, medium and fast.
These don't refer to how fast the program runs.  :)
They refer to how fast the player travels.

In the game, the idea is for the player to be travelling FAST, with the other 2 speeds used to add interesting feedback to collisions.

Quote from: ervin on 02:52, 07 June 12

When the attached program loads, you'll be presented with 3 options: slow, medium and fast.
These don't refer to how fast the program runs.  :)
They refer to how fast the player travels.

This will teach me to read the description before loading the image :D
But why does the line travel slower, the higher it is on the screen? And what's with the colour scheme? :D

The colour scheme is something that isn't locked down yet.
I want to keep the moving lines quite subtle compared to the solid road, but the actual combination of colours is undecided.

The line speeds up as it moves down because it is actually moving towards you.
(Well, not really, but that's the illusion I'm trying to create. Think of it as a 3D road).
The "closer" it is to you, the faster it appears to move.

I know what you mean, but somehow it doesn't look convincing. I'd probably prefer it if they came at me at constant speed (depending on the actual "character"/"hero" speed of course)

It might be hard to imagine the effect I'm after, as there aren't any sprites racing towards you at the moment.
Once they are in, the effect might be more convincing.
I hope.  8)

I'm thinking that if the lines all came toward you at the same speed, it would just look like a vertical scroll.
In any case, I can adjust the speed of the line at every part of the road really easily, due to the way the routine is written.

I see what you mean. Maybe I'm wrong, it's just that it doesn't quite feel... right. Indeed, who knows, maybe it makes sense in your hear because you know what's supposed to be going on in it in the end!

No matter what though, once I have some sprites moving toward the player as they race along the road, I'll certainly be open to suggestions.

Also, thanks for taking the time to give me feedback.
Feedback will get more and more important as development continues.

My pleasure, I really enjoy this progress :)