Recent Posts

Pages: Next page
1
Programming / Re: Sprite moving and leaving crap behind
« Last post by kamelie1706 on Today at 00:59 »
Works perfect, thx ... but now my 2 pixel margin is not enought!
I guess I need 4pixels all around  :doh:
2
Programming / Re: Sprite moving and leaving crap behind
« Last post by Ast on Today at 00:35 »

Hi,

When you add +1 in x, add +4 in y (in mode 0) to keep the same speed in x,y.
3
Programming / Re: Sprite moving and leaving crap behind
« Last post by kamelie1706 on Today at 00:05 »
Great thx!
I went for "fick border", in mode 0 you are on the safe side with 2 pixel all around ... no I need to work on diagonal movement/sprite  :P



https://youtu.be/ihXTHoQXvj4


One aspect I am not yet familiar is the speed movement. The horizontal movement looks way faster than vertical movement ... any trick for that or it is inherent to mode 0?
4
Thanks. If there is a preorder list, please put me on that.  :)


Edit: About the final game, please don't forget to insert some kind of cheat. Then I may have a chance to reach level 2.  ;) :)
5
Amstrad CPC hardware / Re: Zilog peripheral chips
« Last post by GUNHED on Today at 00:02 »
Yes, there is a 257 byte table needed for the CPC - or less in some cases. But using IM 2 does not only enable to use expansions, it also has a great advantage: The lower RAM block can be used completely (for example a 2nd screen, or when using 32 KB V-RAM Overscan, ...).
6
That's interesting becasue I assumed that's how it worked with most beat 'em up type games of that ilk
Saboteur 2 (ported from spectrum) deals only with very small tiles => ninja girl is composed of many small tiles
then it's easy to know if you have to draw the tile with X/Y coordinates => the game is slow because it's a speccy adaptation but this method can perform well
Here is a native usage of this method https://www.cpc-power.com/index.php?page=detail&num=3556
7
in Dragon Ninja game the screen is 64 bytes width but the visible screen is 60 bytes width
i guess the engine assumes sprites are never more than 5 bytes width before doing a real clipping
then you can render any 5 bytes or less sprite as usual, it will warp to the other side of the screen
then before the buffer flipping, the game is drawing two vertical black lines


That's interesting becasue I assumed that's how it worked with most beat 'em up type games of that ilk, in that the actual screen was wider than what the "window" on the screen was. I tended to think that the space to the left or right of the screen was the margins where the maps were being "built" for scrolling, but I was never sure how it worked.

I've had a mess around with the CRTC settings as it has some registers which deal with "actual" screen width and "visible" screen width, but I've not had much luck unfortunately as I don't really know what I'm doing. Still, it's good to know that sort of thing is possible.
8
Here is another game for the GX4000.


This was converted by myself and @Urusergi , thanks to @Nich for the uncompressed crack disk.  8)


METAL ARMY


The game is now Joypad only.


You can now press UP or Joypad 1 Button 2 to Jump.
Console Pause Button to Pause / unpause.
Quit with Joypad 2 Button 1.


You can enter your name in the high score table by using the joypad by default, however there was no space option available so you couldn't put less than four character in, this has now been fixed.  ;)
9
in Dragon Ninja game the screen is 64 bytes width but the visible screen is 60 bytes width
i guess the engine assumes sprites are never more than 5 bytes width before doing a real clipping
then you can render any 5 bytes or less sprite as usual, it will warp to the other side of the screen
then before the buffer flipping, the game is drawing two vertical black lines

10
Programming / Re: Sprite moving and leaving crap behind
« Last post by Arnaud on Yesterday at 21:33 »
Erasing sprites trails all a story !

The easiest solution is your sprite have large border with the color of the background it will overwrite the trails when moving.

Or you have to delete the trail at the previous position of your sprite, with something like that :

Code: [Select]
if (move == TOP)
{
u8* pvideomemTrail = cpct_getScreenPtr(CPCT_VMEM_START, x, y + SP_H + 1);
cpct_drawSolidBox(pvideomemTrail, cpct_px2byteM0(1,1), SP_W, 1);
}
else
if (move == LEFT)
{
u8* pvideomemTrail = cpct_getScreenPtr(CPCT_VMEM_START, x + SP_W + 1, y);
cpct_drawSolidBox(pvideomemTrail, cpct_px2byteM0(1,1), 1, SP_H);
}
else
...





Pages: Next page