CPC Bros

[TFM]

Kannst Du Dumpfbacke einfach mal Deine saublöde Fresse halten? Sicherlich, Dein Englisch ist schlecht. Aber das verstehst Du vielleicht trotzdem:
"
P.S.: I see that some people over are from Germany so I also would like to get in touch with some if there is a coming soon a retro party or so. I am in Reutlingen."


@Gryzor:


It would be very nice if you could stop the constantly provocations by TFM. Thanks!

I did not read his p.s. at first instance, I just tried to help! Looked like you posted - however - in the wrong thread.

[Devilmarkus]

The game progress looks very nice already!
I hope we can play it soon

If you need help, ask me
I'm a vivid source of indefiniteness

(Better don't ask me)

To TFM & Villain:

RELAX TV ☯ 3 Hours of Relaxing Music, Nature Sounds, Ambient Sleep Tracks

[pacomix]

@arnoldemu: he said he accepts criticism But sure, it's looking really good, I'm just offering some notes. Naturally I don't expect it to be perfect!!!


@pacomix: when the character jumps platforms and the sprite rolls, it blinks rapidly - or at least that's what I see in Winape...

Hi! You mean exactly when it gets to a platform when it is falling down, right? That at the moment is something I realized since I implemented the vertical collisions (as you all can see horizontal collisions are not yet implemented) and after taking a quick look I didn't find a solution (yet). That is due to the double buffer that of course I "hope" to fix.
@all:
Regarding the wrong thread/forum messages. That was just a misunderstanding by TFM. No need to start a "fight" for this little thing. We are not so many people so please keep the agressiveness outside. Hehehe. Let there be peace!

[Devilmarkus]

We are not so many people so please keep the agressiveness outside. Hehehe. Let there be peace!

[troll_mode]
Wrong Thread/Forum? 
[/troll_mode]

[Gryzor]

Kannst Du Dumpfbacke einfach mal Deine saublöde Fresse halten? Sicherlich, Dein Englisch ist schlecht. Aber das verstehst Du vielleicht trotzdem:
"
P.S.: I see that some people over are from Germany so I also would like to get in touch with some if there is a coming soon a retro party or so. I am in Reutlingen."


@Gryzor:


It would be very nice if you could stop the constantly provocations by TFM. Thanks!

Also, it'd be quite nice if you kept your language and insults to yourself. We've had enough.

[SRS]

Arrh, a new german game. I like it

Reading this post I do re-think if I should ever put my newest efford (a "samegame" - just logics, no fancy sound or so, and for a small cpc464) into public ... if I ever manage to get those AMSprite on screen *sigh* ...

Back to topic: nice effort, I did see your main figure on Webseite eines Spaniers ... how did you implement sound ? thats one thing I (and my cpc progs) absolutely lack ...

BTW: Grüße in den Süden !

[TFM]

Well, for sound you can use the Wyztracker or the Starkos (probably the most used today) sound files, oh yes, there is also the soundtrakker.
So you basicly have the song-data and player. Now either you put an interrupt in the system, or - for a game - you just call the sound routine once a frame from your program. It depends what you use.

[pacomix]

Arrh, a new german game. I like it

Reading this post I do re-think if I should ever put my newest efford (a "samegame" - just logics, no fancy sound or so, and for a small cpc464) into public ... if I ever manage to get those AMSprite on screen *sigh* ...

Back to topic: nice effort, I did see your main figure on Webseite eines Spaniers ... how did you implement sound ? thats one thing I (and my cpc progs) absolutely lack ...

BTW: Grüße in den Süden !

Personally I am using Wyztracker for the sound. But I didn't look at Starkos or Soundtrakker. So they might perform better than Wyztracker... but I really do not know.
And regarding a new german game... well we can say almost. The pixel artist is from Ibiza and I am originally from Spain but living in Germany. So we can say fifty fifty haha.

[redbox]

Looks like it will be a really cool game.

Why are you going for 15fps...?

I understand the double buffering, but too me it causes such a headache - two screens to update, two loads of backgrounds and sprites to restore and draw.  Or am I missing something?

[pacomix]

Looks like it will be a really cool game.

Why are you going for 15fps...?

I understand the double buffering, but too me it causes such a headache - two screens to update, two loads of backgrounds and sprites to restore and draw.  Or am I missing something?

I am going for 15fps 'cos I couldn't find a way to draw such amount of sprites with backgrounds faster than that...
Regarding the backgrounds and the double buffer... currently the way it works is pretty straightforward ("the way of the donkey"), just populate the affected tiles by the sprites to redraw, redraw them in the "hidden" screen buffer, and draw the sprites over. It is not really a headache. Nothing about saving the affected background somewhere or using a small buffer where to draw the "part to redraw" since we are not using a single buffer. I find the double buffer way faster than having a single buffer at the expenses of one page of RAM of course.
Really having a double buffer is not hard to maintain. The only thing to take in account is the previous and current position for the sprites and which is the active buffer. With that you have all the necessary information to use to populate the affected tiles.
For the detail. I am not using assembler more than for the sprites routines and the Wyztracker (that comes like that). All the logic is C code. And sigh! I am suffering a lot to maintain the code under 12KB right at the moment. 
Suggestions? More than welcome of course!


By the way... does any of you know who is the holder of the Snow Bros copyright?

[ralferoo]

I only just got round to looking at the youtube video - those sprites are lovely! Just wondering if you'd actually be better to lock at 12.5fps rather than 15fps so that each screen is drawn in exactly 4 frames. 15 fps means you'll have some shown for 3 frames and some for 4, so it won't look quite as smooth...

[TFM]

Or it means they are all shown in 3 frames, and the 16.666666666666666666666666667 was just rounded to 15 

[redbox]

currently the way it works is pretty straightforward ("the way of the donkey"), just populate the affected tiles by the sprites to redraw, redraw them in the "hidden" screen buffer, and draw the sprites over. It is not really a headache. Nothing about saving the affected background somewhere or using a small buffer where to draw the "part to redraw" since we are not using a single buffer. I find the double buffer way faster than having a single buffer at the expenses of one page of RAM of course.
Really having a double buffer is not hard to maintain. The only thing to take in account is the previous and current position for the sprites and which is the active buffer. With that you have all the necessary information to use to populate the affected tiles.

Thanks for the explanation - I understand how you're doing it and it's a nice way.  Will try it myself 

[arnoldemu]

Regarding the backgrounds and the double buffer... currently the way it works is pretty straightforward ("the way of the donkey"), just populate the affected tiles by the sprites to redraw, redraw them in the "hidden" screen buffer, and draw the sprites over. It is not really a headache. Nothing about saving the affected background somewhere or using a small buffer where to draw the "part to redraw" since we are not using a single buffer. I find the double buffer way faster than having a single buffer at the expenses of one page of RAM of course.
Really having a double buffer is not hard to maintain. The only thing to take in account is the previous and current position for the sprites and which is the active buffer. With that you have all the necessary information to use to populate the affected tiles.

I use this method in a couple of games I have in development.

I have a list for each buffer.
I push the x,y,width and height into the list.

When the buffer is swapped, I swap the list. (I actually swap the pointer to the list ).

Then I read through the list, work out the rectangle of tiles to redraw and draw them. Then empty the list and start again for this buffer.

This works good.

There is overdraw if more than one sprite is over the same tiles, but I accept this with my current games.

The double buffer really helps!

[pacomix]

I use this method in a couple of games I have in development.

I have a list for each buffer.
I push the x,y,width and height into the list.

When the buffer is swapped, I swap the list. (I actually swap the pointer to the list ).

Then I read through the list, work out the rectangle of tiles to redraw and draw them. Then empty the list and start again for this buffer.

This works good.

There is overdraw if more than one sprite is over the same tiles, but I accept this with my current games.

The double buffer really helps!

I do it in a similar way but avoiding the redraw and with only one buffer, which depending in the amount of verschiedene tiles you use can be possible or not.
I store for every sprite the current coordinates and the coordinates where they were drawn in the buffers.
In the paint loop, first of all, take a look in which buffer the sprite will be painted and for each of the sprites:
    - Populate the affected tiles for the position the sprite had in that buffer.


After that loop just paint the tiles affected.


Then another loop for every sprite again:
    - Paint the sprite in the required buffer (the hidden one) with the current coordinates of it.
    - Store the current position in the required set of coordinates for the just painted buffer.
    - Call sprite's state machine
    - Flip the buffers
In order not adding twice or more the tiles to the populated tile list, what I do in the populate function, is setting a flag in the byte where I store the tile info (tile number) when I add it to the list, and before adding it I check if that flag was already set ignoring the add if so. And in the tile paint function I reset that flag just before painting it. That avoids the redrawing and the need of having two separate lists. One for each buffer.
But of course... depending the amount of different tiles you use in the game, this could be an affordable way or not. In my case I am limited to 32 different tiles (5 bits) because I make use of 1 bit to tell if a tile should be drawn with mirroring, another one to tell if it is a platform and another one for the purpose I have just described. But right at the moment it is enough.
That could add a little of overhead when creating the list of tiles-to-be-painted but I guess it is nothing in comparison with the overhead of redrawing them.


And regarding the double buffer. It helps a lot regarding the speed of painting yes since you avoid drawing everything to another small buffer before copying it to the main screen buffer. But yes... at expenses of having 16KB less. (sigh!)

[pacomix]

I only just got round to looking at the youtube video - those sprites are lovely! Just wondering if you'd actually be better to lock at 12.5fps rather than 15fps so that each screen is drawn in exactly 4 frames. 15 fps means you'll have some shown for 3 frames and some for 4, so it won't look quite as smooth...

I didn't think about that. But you are right.
At the moment I am not switching  the buffers in sync with the VLB and I have just noticed some minutes ago a slight flicker from time to time in some sprites. If that happens more often I will have then to sync the switching of the buffer with the VLB or, automatically adjust the switching depending on the time spent in the paint loop like some portable consoles does in example.

[Snake_Plissken]

Any news ?

[pacomix]

Hi Snake!

   Unfortunately not... Too many things changed last year in my life and I needed to disconnect a bit from the computers. But it is a thing still pendant to finish.

Paco

[romppainen]

Hopefully you'll find time and strenght to finish it, what you've achieved so far looks very promising.

[Snake_Plissken]

any preview to test ?

[tastefulmrship]

Amazing looking game, can't wait to see it in action on real hardware! TOP STUFF!




NOTE: The music, in the initial YooToob vid, is the Wyztracker version of Stargazer's Amiga mod called Shampoo. The version in the vid is very funky, I like it a lot! It's better than my STArkos version (which is WIP... the arpeggios need to be a higher volume!)

[pacomix]

any preview to test ?

Hi Snake! Apart of the two videos that are in Youtube (one in my account Pacomix64 and another one in the account Juan Esteban) there is nothing to test still. I added the shots and two more enemies. I was thinking in releasing a 128KB version only since I'm running out of RAM mostly due to the double buffer but I want to have a cassette release too for the 464's. Maybe by reducing sprite frames and tiles would be possible...
I did a test with a single buffer screen last month but the game would loose a lot of speed turning it into a non-pleasant experience.

Amazing looking game, can't wait to see it in action on real hardware! TOP STUFF!
NOTE: The music, in the initial YooToob vid, is the Wyztracker version of Stargazer's Amiga mod called Shampoo. The version in the vid is very funky, I like it a lot! It's better than my STArkos version (which is WIP... the arpeggios need to be a higher volume!)

Thanks Jonah! Yep... the music is amazing. Really well converted! I like it even more than the original one. I took it just for testing.


Regards!

[remax]

With memory expansions easily available these days, that would be sad to downgrade the game because of memory problems from the lowest part of the range

[Carnivius]

Hi Snake! Apart of the two videos that are in Youtube (one in my account Pacomix64 and another one in the account Juan Esteban) there is nothing to test still. I added the shots and two more enemies. I was thinking in releasing a 128KB version only since I'm running out of RAM mostly due to the double buffer but I want to have a cassette release too for the 464's. Maybe by reducing sprite frames and tiles would be possible...
I did a test with a single buffer screen last month but the game would loose a lot of speed turning it into a non-pleasant experience.

Would be shame cos I was looking forward to playing this on my 464 but I understand if not possible.

[sigh]

Is this still being worked on?