Space Pest Control (Development)

[reidrac]

Don't be shy, it's faster than yours. :-D

Good job for your game. I put some words in Amstrad Plus Forum.

How do you know how my ISR looks like?  Yes, it is a waste of time to increase my counter every 300Hz when 50Hz is enough resolution to calculate the FPS.

So at 300Hz, do you get only one interrupt per vsync?

[reidrac]

Don't be shy, it's faster than yours. :-D

Good job for your game. I put some words in Amstrad Plus Forum.

Actually, I think is about 3 t-states faster than mine. oooh!

[Ast]

Now i know ;-)

[ronaldo]

Actually, I think is about 3 t-states faster than mine. oooh!

Beware! Amstrad CPC timing is not general Z80 timing (like in the ZX, for instance). All instructions execute in multiples of 1 microsecond (4 t-states) because the way Z80 CPU is controlled by the CRTC. This model was done to prevent concurrent access to memory between CRTC and Z80.

You have the "CPC Timings" here: Timings

And a nice table made with them here: http://wiki.octoate.de/lib/exe/fetch.php/amstradcpc:z80_cpc_timings_cheat_sheet.20131019.pdf

PS: I was making the same mistake time ago until @Prodatron told me .

[arnoldemu]

So at 300Hz, do you get only one interrupt per vsync?

yes.

If your interrupt service routine takes too long (more than 32 scanlines or 64*32 cycles) that can cause the position of the next interrupt following it to move.

If it happens at the interrupt before the one where vsync is active, then the one that occurs at vsync will move and you will not see the vsync happen.

Generally though, not that much is done in the interrupts so this will not be a problem for you.

[reidrac]

Beware! Amstrad CPC timing is not general Z80 timing (like in the ZX, for instance). All instructions execute in multiples of 1 microsecond (4 t-states) because the way Z80 CPU is controlled by the CRTC. This model was done to prevent concurrent access to memory between CRTC and Z80.

You have the "CPC Timings" here: Timings

And a nice table made with them here: http://wiki.octoate.de/lib/exe/fetch.php/amstradcpc:z80_cpc_timings_cheat_sheet.20131019.pdf

PS: I was making the same mistake time ago until @Prodatron told me .

Very interesting!

I'll check it better this evening, but looks like my code could be faster after all. @arnoldemu code uses extra push/pop plus in (4 usecs!). Besides I may need to change WYZ code if I change how often its ISR is changed called.

Thanks!

[Ast]

Some words about Push'n Pop.
Noticed that  :

Pop af, de, bc and hl take only 3 us
Pop ix and iy take 4 us
---
Push af, de, bc and hl take 4 us
and last
Push ix and iy take 5 us.

It's more readable like that, don't you think ?

[ronaldo]

Yes, @Ast, you are right. POP IX/IY take only 4 us, but they appear as 5 us on both documents.

@Octoate, @arnoldemu, could you please update documentation with correct us value for POP IX/IY?

Thanks to all of you 

[reidrac]

Following general advice, I'm putting together a version of the game that I'll submit to the compo; and continue working on it after that to make a final release.

Interestingly enough looks like I may run out of memory before I run out of time... and that probably means I have to rethink some part of my rough plan because otherwise the final release would be a short game

So I'm not sure I'll post more updates until I submit the game. Bear with me!

[ervin]

Following general advice, I'm putting together a version of the game that I'll submit to the compo; and continue working on it after that to make a final release.

Interestingly enough looks like I may run out of memory before I run out of time... and that probably means I have to rethink some part of my rough plan because otherwise the final release would be a short game

So I'm not sure I'll post more updates until I submit the game. Bear with me!

Really glad to hear it!
I wish you all the best with your entry - I think you'll do well.


Just wondering - what are you writing the game in?
Is it a cpctelera project?

[reidrac]

Really glad to hear it!
I wish you all the best with your entry - I think you'll do well.


Just wondering - what are you writing the game in?
Is it a cpctelera project?

The game is written in C and some assembler (when needed, for speed), and a good amount of Python for auxiliary tools (converting maps from tiled into C structures, generating the font, png to sprite, etc).

I'm using SDCC (C & ASM) and cpcrslib for music (includes WYZ support), text and some utilities; the tile/sprite engine is being developed for this game.

I may write the missing bits and use my tile/sprite engine + WYZ for future games; but for now cpcrslib is very useful and a real time-saver!

[Xifos]

Hello, your game looks good.


What version of sdcc have you ?

Do you use double buffering for sprites ?

[reidrac]

Hello, your game looks good.


What version of sdcc have you ?

Do you use double buffering for sprites ?

I use latest stable release (not using the new Z88DK fastcall thing).

I implemented a back buffer for the tile engine, and that's one of the reasons I'm getting out of memory at this point. I could try to reduce the amount of memory used for that and be a little bit slower, but the saving would be less than 1 KB so I think is not worth it.

I could also reduce the game area, from 160 x 160 to let's say 144 x 140 (that would give me 2720 juicy bytes back), or just convert some C to ASM.

Anyway, still have around 6 KB left to wrap up the submission. I think is possible!

[Xifos]

How does this back buffer work ?
Could you explain please ?
i am interested in the various ways to avoid flickering sprites, with a tile engine.

Thanks !

[reidrac]

How does this back buffer work ?
Could you explain please ?
i am interested in the various ways to avoid flickering sprites, with a tile engine.

Thanks !

You can find lots of information if you search for it, probably better explained than anything I can write here!

Basically I keep a buffer using a continuous memory layout (easier to deal with than the CPC video memory layout) that is used to compose the scene, and then copied to video memory as fast as possible following the vsync (to avoid tearing, flickering, etc).

Copying the whole buffer every time is too slow. How do you update video memory fast enough then? I don't do it! I just track which parts of the buffer are in sync with video memory and which ones are "dirty", so every frame I copy only differences.

The buffer is split in "cells" of the size of a tile, and that's the "background image" information. So for each frame I collect information (erase the player, draw next frame in a new position) that is translated to back buffer operations (restore the tile in each cell than needs erasing, copy any sprite, etc).

When the work is done, just wait for vsync and copy any dirty cell to video memory.

I could do it faster, but I'm happy keeping it simple (compared with other engines I know, for example SP1 for the speccy).

I hope this helps!

[Xifos]

Ok !
I understand.
But it takes 25600 bytes, 12800 for the linear back buffer, 12800 for the screen.
So 144*140 should save 2720*2 ?

(maybe i did not understand  )

[reidrac]

Ok !
I understand.
But it takes 25600 bytes, 12800 for the linear back buffer, 12800 for the screen.
So 144*140 should save 2720*2 ?

(maybe i did not understand  )

Video memory is video memory, I don't think you can change that. I can reduce the back buffer size, that's all.

[ronaldo]

Video memory is video memory, I don't think you can change that. I can reduce the back buffer size, that's all.

In the Amstrad CPC you can. Video memory is controlled by the Gate Array and the CRTC. You can change resolution, colours, location... Following some rules, you can create your own resolution, as many games do. I think that @Xifos is referring to that.

In fact, I'd only use a software backbuffer if it was a small backbuffer. If my backbuffer was same size as video memory, I'd definitely use hardware double buffering (which is as easy as changing registers R12/R13 when you want to move your video memory to the backbuffer area and back again). Well, at least in the majority of the cases: there may exist some special cases for not doing that, but I can't think of one right now.

[Xifos]

It's true that the unused video ram is not linear.
Because of the screen memory layout.
But it can be useful for storing some variables...

EDIT : i forgot to count the score panel, so video ram is used in fact...
As ronaldo said, you could use another screen size, with 64 bytes lines, but you get a greater border...

[reidrac]

OK, just to let you know: I submitted Space Pest Control to CPC Retro Dev 2015.

That means you'll have a playable game after October 31st when the contest results are out.

I plan to have a break and continue working on the game, hopefully after getting some feedback after you guys play the compo version

[TFM]

Glad you made it! Looking forward to play it! 

[reidrac]

Well, the compo is over and... Space Pest Control was nominated in the PRO category! That's pretty good for my first Amstrad CPC game, specially taking into account how I rushed to be able to submit something.

Obviously winning one of the prizes would have been even better ; but after I saw some of the games during the streaming of the ceremony... oh, dear; I didn't have a chance! Amazing games that definitely have tons of hours of work put into them! Congrats to the winners!

Anyway, I'm releasing Space Pest Control "CPC Retro Dev" edition (plus some minor bug fixes, but the game is the same that was submitted to the compo; also you'll be able to download the game from the compo site and eventually buy the cassette with the game on it).

You can grab the game (both CDT and DSK) from here: Amstrad CPC: Space Pest Control - usebox.net

Just one stage, with three different areas (one of them is "disconnected", if you go there too soon you may not be able to get the pest level to 0% and finish the game). Only three different types of enemy and 25 screens. There's still room left for more, but that's the best I could do before the deadline!

Feedback is welcome, but please take into account how this was put together (meaning: be gentle  ).

[Fessor]

Pffff... there is no reason being gentle because you have no reasond to hide. Yes, it may be a dev-version and it may be your first game. But even at this stage it is much better than most of the crap the companies have thrown on the market back in the past. No flickering Sprites, no noticable slowdowns, nice Effects. It was right that it was nominated at the pro category, and this for itself is a victory. Its a raw diamond and i hope you spend more dev time on it.

[Singaja]

Yay. This is super smooth and I luv the style. I really like the concept of enemies at different heights in game shooting mechanics. I find the jumps most challenging, you could give the main character a little more time in the air. With such level design a jetpack or some other floating device could be really fun too. I'm a noob cpc coder so technically I'm super impressed what you got so far

[arnoldemu]

my comments:

- nice loading screen

- nice main menu. colourful, easy to use. reminds me of many Spanish made games

- i like i can press fire on joystick to start game. but press space on game over screen and not fire?

- in-game graphics are colourful and smooth.

- difficulty is good.

- a nice exploration game.