News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_ronaldo

#CPCtelera 1.4.2. release

Started by ronaldo, 11:59, 11 May 15

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

AMSDOS

Quote from: ronaldo on 09:59, 09 August 15
It's done shifting sprite bytes for every movement. You can check the full code of the move1pixel example: it's included with latest version of CPCtelera :) .


Ok, so if I'm reading it properly you're dividing the number of pixels per byte to generate the effect.
* Using the old Amstrad Languages :D * And create my own ;)
* Incorporating the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

ronaldo

Not exactly. CPCtelera's drawing functions draw sprites at byte locations. Division is there to convert pixel coordinates to byte locations.

The 1-pixel movement is based on shifting functions (shiftSpritePixelsRight / shiftSpritePixelsLeft). Each shift moves the sprite 1 pixel to the left or to the right in-place (inside the sprite buffer). Then the sprite is drawn normally copying bytes to screen with cpct_drawSprite function.

arnoldemu

Quote from: EgoTrip on 14:02, 08 August 15
Cygwin can fuck off.
I believe EgoTrip's point is that for windows users there is no simple one click installer?




My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

ronaldo

@arnoldemu: Having one-click installers would be marvellous. If someone wants to develop and maintain them, I would be more than happy :D.

EgoTrip

Well yeah, a 1-click would be nice. However, sitting around waiting for an hour to download, then 2 hours later it still had not finished installing, I just gave up cos there was no sign of it ever ending. All I did was try to install the devel package for gcc. Nothing else.

I'm going to try CPC Basic but thats not really going to  cut it from what I can gather. I need a proper coder who knows what they are doing really but nobody wants to get involved, theres no financial incentive and maybe my game ideas are just crap really.

ronaldo

@EgoTrip: That happens when you select a slow mirror for Cygwin. It has happened to me sometimes. Last time I was waiting for 10 minutes, then I cancelled, picked up a different mirror and everyting installed in 3 minutes.

Organizations set up mirrors with their own means and they are not always able to cope with demand.

AMSDOS

Quote from: ronaldo on 10:26, 09 August 15
Not exactly. CPCtelera's drawing functions draw sprites at byte locations. Division is there to convert pixel coordinates to byte locations.

The 1-pixel movement is based on shifting functions (shiftSpritePixelsRight / shiftSpritePixelsLeft). Each shift moves the sprite 1 pixel to the left or to the right in-place (inside the sprite buffer). Then the sprite is drawn normally copying bytes to screen with cpct_drawSprite function.


Cool, so the bytes are either Added or Subtracted by &55 to obtain the next pixel position.
* Using the old Amstrad Languages :D * And create my own ;)
* Incorporating the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

ronaldo

As discussed yesterday, there is another occurence of the tail jumping bug when using __z88dk_callee functions in SDCC 3.5.0. This is a critical bug, as programs suffering it crash due to a bad optimization made by the compiler.

So, we have issued a new bugfix release of CPCtelera, fixing this bug. Everyone is urged to update.

You have more details on this update on its release notes.

ervin

Quote from: ronaldo on 08:18, 14 August 15
As discussed yesterday, there is another occurence of the tail jumping bug when using __z88dk_callee functions in SDCC 3.5.0. This is a critical bug, as programs suffering it crash due to a bad optimization made by the compiler.

So, we have issued a new bugfix release of CPCtelera, fixing this bug. Everyone is urged to update.

You have more details on this update on its release notes.

Thanks ronaldo.
I'm very happy to see cpct_isAnyKeyPressed in this release.
:)


ronaldo

Yes, @ervin, I implemented the functions when you suggested it, so I only had to write documentation and include them in the release :) .

It might also be more interesting for you the new feature I have just commited to the main branch (that will be available on next releases). Now CPCtelera automatically manages .bin files included under src/ folder. It detects them and automatically makes the conversion to .c array that is compiled and included in the project. It also detects any change to the .bin files and redoes the conversion when this happens. You don't have to worry anymore about manually converting your binary files: you only save them to a folder under src/ and they are automatically managed :) .

There is a very simple example under examples/medium folder (incbin example).

ervin

Quote from: ronaldo on 16:57, 14 August 15
Yes, @ervin, I implemented the functions when you suggested it, so I only had to write documentation and include them in the release :) .

It might also be more interesting for you the new feature I have just commited to the main branch (that will be available on next releases). Now CPCtelera automatically manages .bin files included under src/ folder. It detects them and automatically makes the conversion to .c array that is compiled and included in the project. It also detects any change to the .bin files and redoes the conversion when this happens. You don't have to worry anymore about manually converting your binary files: you only save them to a folder under src/ and they are automatically managed :) .

There is a very simple example under examples/medium folder (incbin example).

Now THAT is a feature I will find very useful!
Thanks for implementing it.
:)

arnoldemu

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

AMSDOS

You might need a "Clear Input" Void to go with that "Any Key" Routine?
* Using the old Amstrad Languages :D * And create my own ;)
* Incorporating the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

ronaldo

@AMSDOS: "Clearing input" is a concept used when using intermediate buffers between keypresses and software key reads. That's not the case here. Keyboard functions access the present status of the keys. So, if a key is being pressed, there is no way to "clear it" as you only can wait for the user to stop pressing it. In other words, the status will be "pressed" until the user releases it.

So, using cpct_anyKeyPressed(), the solution is using 2 loops: a first loop that waits until no key is pressed and then, another loop that waits for a keypress. That's the way to ensure that a key has been pressed voluntarily by the user. This is a code sample for doing that:

void wait4Keypress() {
   // First, if there is any key pressed, we wait until no key is pressed
   do { cpct_scanKeyboard_f(); } while ( isAnyKeyPressed() );

   // Then we wait until a Key is pressed
   do { cpct_scanKeyboard_f(); } while ( !isAnyKeyPressed() );
}

AMSDOS

Yeah so usually what happens is a buffer of user input has been generated, and needs to be cleared, otherwise the Any key routine just does it's own thing, which could be taking you back into the game and if your lucky some user input from earlier if running the game.
* Using the old Amstrad Languages :D * And create my own ;)
* Incorporating the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

ronaldo

[quote
Quote from: AMSDOS on 09:51, 16 August 15
[...] what happens is a buffer of user input has been generated, and needs to be cleared, [...]
That usually happens on nowadays machines and operative systems. OS are those who create and maintain buffers for user input. That does not happen on a CPC when you directly program its hardware, like CPCtelera does. All keyboard functions from CPCtelera do scan and report present keyboard status, with no input buffers (not like modern OSes).

AMSDOS

I see what your saying, but what I'm asking is does the "Any Key" Routine need something to clear the buffer? I would have thought the Hardware Especially keeps a Buffer of Backlogged key-presses, otherwise you've got yourself a computer ignoring Key-presses.
Would of thought something for Clearing the Buffer needed to be kept separate from an "Any Key" routine, I don't know, just thought that if the Buffer was Cleared before the "Any Key" routine was called, would a key become ignored?
* Using the old Amstrad Languages :D * And create my own ;)
* Incorporating the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

ronaldo

#267
Quote from: AMSDOS on 10:22, 16 August 15
I'm asking is does the "Any Key" Routine need something to clear the buffer? I would have thought the Hardware Especially keeps a Buffer of Backlogged key-presses, otherwise you've got yourself a computer ignoring Key-presses.
No, hardware does not have any buffer. Keyboard is directly scanned to see if keys are pressed or not.

Quote from: AMSDOS
I don't know, just thought that if the Buffer was Cleared before the "Any Key" routine was called, would a key become ignored?
Keys could be ignored if your keyboard scanning frequency is low, and a user presses and releases a key between two scans. If you scan keyboard 25/50 times per seconds that's unlikely. However, as your frequency decreases, you may experience ignored keys. In fact, you can see this happening on lot of games with low framerate (as they may be scanning keyboard once per frame drawn to screen).

AMSDOS

I guess this is where games were tested for playability and reviewers would say if a game was unplayable. So it would seem there was more than one way of scanning the keyboard. Even on @arnoldemu website there's a routine which is considered CPC Plus unfriendly.
* Using the old Amstrad Languages :D * And create my own ;)
* Incorporating the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

ronaldo

#269
Quote from: AMSDOS on 11:56, 17 August 15
I guess this is where games were tested for playability and reviewers would say if a game was unplayable. So it would seem there was more than one way of scanning the keyboard. Even on @arnoldemu website there's a routine which is considered CPC Plus unfriendly.
To my knowledge, there is only one way of scanning the keyboard. You can arrange it in multiple ways (scan only some keys, scan the complete keyboard, store scanned status or not...), but I only know of a way to scan it.

Anyways, the kind of unplayability you are referring comes from low scan frequency, not from different ways of scanning. Games tend to scan for user input once on every iteration of the game loop. If a game runs at 6 FPS, that lefts the player with a maximum of 6 actions per second. Moreover, you may have a delay up to 0,16s between a keypress and its reaction. That drives the game unplayable, in most cases.

AMSDOS

Quote from: AMSDOS on 11:39, 11 August 15

Cool, so the bytes are either Added or Subtracted by &55 to obtain the next pixel position.


i tested this out, though my comment isn't correct in the sense it's not being added or subtracted, but shifted, and for a graphic to shift from one spot to another depending on direction relies on it being shifted by either &55 or &AA which are based on Left Most Pixel or Right Most Pixel in a 7 or 8 bit format.


The routine obviously works, though I cannot workout (from a sprite driver I made a few years ago, which allows for 1 byte pixel movement), the encoded byte results from it.


For example a Left Byte Position looks like this:


&C0,&40,&40,&80


which becomes:


&40,&80,&80,&C0


Don't think I'm shifting based on Byte positions.
* Using the old Amstrad Languages :D * And create my own ;)
* Incorporating the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

Paulo Garcia

Hey Ronaldo, I am curious...why did you remove the maze game example from master branch?


Cheers




andycadley

Quote from: AMSDOS on 11:55, 19 August 15

i tested this out, though my comment isn't correct in the sense it's not being added or subtracted, but shifted, and for a graphic to shift from one spot to another depending on direction relies on it being shifted by either &55 or &AA which are based on Left Most Pixel or Right Most Pixel in a 7 or 8 bit format.


The routine obviously works, though I cannot workout (from a sprite driver I made a few years ago, which allows for 1 byte pixel movement), the encoded byte results from it.


For example a Left Byte Position looks like this:


&C0,&40,&40,&80


which becomes:


&40,&80,&80,&C0


Don't think I'm shifting based on Byte positions.

&55 and &AA wouldn't be values to shift by, they'd be pixel masks to AND with. You're encoding each byte so that both the left and right pixels are set to the same Pen, then you can extract the left pixel by ANDing the encoded value with &AA or the right pixel by ANDing with &55. The two subsequent values can then be OR'd to get the final value to write to the display.

AMSDOS

Quote from: andycadley on 23:18, 19 August 15
&55 and &AA wouldn't be values to shift by, they'd be pixel masks to AND with. You're encoding each byte so that both the left and right pixels are set to the same Pen, then you can extract the left pixel by ANDing the encoded value with &AA or the right pixel by ANDing with &55. The two subsequent values can then be OR'd to get the final value to write to the display.


I wrote this little example using AND to move left and right pixels to the Right:



org &4000

ld a,(&c000)
and &aa
ld (&c001),a
ld a,(&c000)
and &55
ld (&c000),a



I guess to implement it in a working environment, it would be applied from the Right Edge of the Sprite, moving backward though a loop and going down. Which I presume would mean the opposite when moving the Sprite Left.
* Using the old Amstrad Languages :D * And create my own ;)
* Incorporating the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

ronaldo

Quote from: Paulo Garcia on 21:17, 19 August 15
Hey Ronaldo, I am curious...why did you remove the maze game example from master branch?
Because I merged it to the master branch by mistake. It's still under development, on its own branch. It will return to master branch once finished ;).

Powered by SMFPacks Menu Editor Mod