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.

Carnivius

Oh I see.  So the cygwin terminal is still my access to cpctelera rather than cpctelera being a seperate exe program like it would be on windows?   Ok I made a new project and I see in explorer that a new folder got made.  I can see main.c in explorer.  That's my main game code scripty thing right?   How do I view that properly?  (I tried opening in notepad and while it loaded the actual text fine, it was all over the place and hard to read).
Favorite CPC games: Count Duckula 3, Oh Mummy Returns, RoboCop Resurrection, Tankbusters Afterlife

mr_lou

Quote from: Carnivac on 15:36, 10 July 15
Oh I see.  So the cygwin terminal is still my access to cpctelera rather than cpctelera being a seperate exe program like it would be on windows?   Ok I made a new project and I see in explorer that a new folder got made.  I can see main.c in explorer.  That's my main game code scripty thing right?   How do I view that properly?  (I tried opening in notepad and while it loaded the actual text fine, it was all over the place and hard to read).

The "all over the place" problem is due to how line-endings are done on the various systems.
Notepad only reads Windows line-endings, and the main.c file clearly contains Linux line endings.
I think that SDCC probably compiles your C program with Windows line-endings too, so if you just clean up the file first, then you can continue from there.
Otherwise, all you need is another editor, like e.g. Notepad++ or PSPad. They will handle Linux line-endings just fine.

Carnivius

Ah good ol' PSPad.  One of the few programs I used a lot on my laptop that I forgot to install on my new pc.

Ok it's displaying correctly and I'm looking at game.c of the platform climber example to get an idea of how it works (after having run the dsk of that example in Winape to see what the results are).   The general structure of it reminds me of GML in Game Maker: Studio which I use to make games on PC so it's not completely alien to me fortunately.   It'll just take some time to learn what functions do what and get used to the general environment of the software.

Starting to feel a bit more confident about it.  I can't say I'll be coding the CPC code of RoboCop: Prime in it any time soon but I want to try coding a much simpler game just to get a feel for how this all works and go on from there.   Just gonna study the scripts and try change bits here and there to see what does what to the platform climber example.


By  the way what is the relevance of the .c and .h file extensions?
Favorite CPC games: Count Duckula 3, Oh Mummy Returns, RoboCop Resurrection, Tankbusters Afterlife

Trebmint

Its really great this framework seems to have taken off and got people coding. I always thought that there were people that wanted to code games just that the sheer difficulty in getting something setup and working, and a lack of decent tools were hampering developments. Seems we now have a winner and a way forward. Great stuff ronaldo. Looking forward to seeing some of the results :)

mr_lou

Quote from: Carnivac on 15:56, 10 July 15By  the way what is the relevance of the .c and .h file extensions?

I would be the wrong person to try to explain this, as I still don't know entirely myself.  :)
But you can most probably find some info about it online fast if you google for it, as it is common C style programming.

ervin

Quote from: Carnivac on 15:56, 10 July 15
Starting to feel a bit more confident about it.  I can't say I'll be coding the CPC code of RoboCop: Prime in it any time soon but I want to try coding a much simpler game just to get a feel for how this all works and go on from there.   Just gonna study the scripts and try change bits here and there to see what does what to the platform climber example.

Well done on getting cpctelera working - great stuff.

I reckon a bunch of us should start to work together on bringing Robocop:Prime to life.
(Well, maybe after CPCRetroDev2015 is over).

Perhaps we could identify different tasks and hand out different portions of the program to those that are most comfortable with particular aspects.
Then we might one day see those *magnificent* graphics come to life on a CPC!

Carnivius

Let's not get ahead of ourselves.  Pressure pressure  :o

Favorite CPC games: Count Duckula 3, Oh Mummy Returns, RoboCop Resurrection, Tankbusters Afterlife

ronaldo

@ervin, @mr_lou: thanks for your appreciation, it is very nice to see you wanting to create things and I'm looking forward to see your productions :) . However, as your experience and @carnivac's shows, there is still much work to do to have a really easy framework for anyone. CPCtelera may have improved some things, but that's just one step: there are may things to be improved. And, of course, this is a great thing: we have lot of work ahead to develop and enjoy :) .

@carnivac: I'm sorry. I'd love to have developed something really comfortable for everyone. CPCtelera is based on Linux, what makes it work almost immediately on Linux and OSX, but requires Cygwin on Windows. It also requires some familiarity with Linux. I hope we can improve it to make it much easier for everyone on the future, but my limited time prevents me from evolving it faster. Anyway, I'll try to help you as much as possible :)

However, if all of you like (@carnivac, @mr_lou, @ervin, @Paulo Garcia, @lachlak and anyone else), you may help me improve it and make it easier for others. The first thing I purpose is that you log all your initial problems with CPCtelera and your solutions. If you log it with great detail, that can be used for:

       
  • Create a help page with lot of interesting explanations for others
  • Detect things that can be improved and create a task list
  • Provide base for better usability designs and ways of explaining and introducing people to development.
Your experience is really valuable for others and would be awesome to have it structured in CPCtelera to improve it :) .

mr_lou

Quote from: ronaldo on 19:34, 10 July 15I hope we can improve it to make it much easier for everyone on the future, but my limited time prevents me from evolving it faster.

The biggest problem we all have: Not enough time.  :(
I vote that someone on the forum should win the european lottery, and then finance all developers here so they can quit their jobs and make Amstrad CPC stuff all the time.  :)

ronaldo

Quote from: Carnivac on 15:56, 10 July 15
By  the way what is the relevance of the .c and .h file extensions?
There almost nothing inherently different between a .c and a .h file. The use is .c files contain code (definitions) and .h files contain declarations. This is because C compiler only needs to know that a given function/variable/constant/type exists, along with its types, to know what to do when you use it. For instance, when you write something like this:

if ( cpct_isKeyPressed(Joy0_Up) ) {
   // ... your code here
}

C compiler doesn't know what the hell means "cpct_isKeyPressed" unless you tell it what it is. To tell it what it is you can do it directly, declaring it:

u8 cpct_isKeyPressed(cpct_keyID key);

void main () {
  // ...
  if ( cpct_isKeyPressed(Joy0_Up) ) {
     // ... your code here
  }
  // ...
}

Now you are telling the Compiler what cpct_isKeyPressed is (declaring it) and then, when the compiler founds the if, knows how to generate code for the call. Declarations for u8 and cpct_keyID types should also be provided, but I left them out for simplicity.

When you only need to declare a function, this is enough. However, when you have lots of functions, variables, constants, etc, you group them in a header file (.h) which only includes declarations. Then, to include all the declarations for the compiler in your code, you only have to do this:

#include <cpctelera.h>

void main () {
  // ...
  if ( cpct_isKeyPressed(Joy0_Up) ) {
     // ... your code here
  }
  // ...
}

Therefore, the use for the header files (.h) is grouping these declarations that inform the compiler about the existence of other functions/variables/constants, etc. When you use #include, you are including the contents of the header file, including this declarations, not having to rewrite them everytime you need them.

One more thing: this is just informing the compiler about things that exist and their typing. Later, the linker is responsible for linking these existing things in the final binary code. You can fool the compiler telling him that a non-existing function exists and it won't complain. Later on, the linker will tell you that it does not exist when it tries to include the actual definition (the code) of the function.

Regarding the editor, I recommend you either Notepad++ or Sublime, which are really great as editors :)

Paulo Garcia

Quote from: ronaldo on 19:34, 10 July 15

However, if all of you like (@carnivac, @mr_lou, @ervin, @Paulo Garcia, @lachlak and anyone else), you may help me improve it and make it easier for others. The first thing I purpose is that you log all your initial problems with CPCtelera and your solutions. If you log it with great detail, that can be used for:

       
  • Create a help page with lot of interesting explanations for others
  • Detect things that can be improved and create a task list
  • Provide base for better usability designs and ways of explaining and introducing people to development.
Your experience is really valuable for others and would be awesome to have it structured in CPCtelera to improve it :) .


I have already forked it on Github, and I am slowly learning how to use it. My problem as you know is that I never had a Amstrad CPC before, and I am not aware of its internals. I suggest to use the Github issues on lronaldo/cpctelera · GitHub to add bugs or suggestions.


As a complete cpc-noob, I might be able to help to get it easier to use. So far I found it very easy to build examples though (on Mac OSX).


Now, I've found a CPC-464 on sale here in Canada, but for $400 (CAD) I will have to stick with emulators to test my creations :)


Cheers


Paulo






lachlank

As a Windows user, here is my current full setup for doing CPC dev.

       
  • VS Code as text editor/Git client
  • WinApe for testing/debugging
  • Cygwin to make
  • RGAS to create graphics (generally I will import existing images as I can't draw to save myself)
  • Paint.Net for any graphics work outside what RGAS can do (this free program is absolutely brilliant)
I've shown a couple of really useful books I keep on hand.

       
  • The C Programming Language by Kernighan & Ritchie. This is my computer science textbook from 1995 that I found at my parents' house and is brilliant as a quick (re)introduction and as reference.
  • Machine Code for beginners on the Amstrad. This or any good z80 reference for when you need to drop into assembly or interpret .rst files (more on that below).
A really useful output from the SDCC linker are the .rst files produced for each input .c and .s file (in the obj folder). These show the assembly generated for each .c source line, as well as absolute addresses. This allows you to effectively set breakpoints in your .c code:



       
  • Get address from .rst file.
  • Load program in Winape
  • Pause and show Assembler
  • Press the "Go to address" button at bottom, and enter hex address.
  • Click in the margin to set a breakpoint
  • Although it doesn't seem to be documented anywhere, you can step over using f8 and step into using f7 from the WinApe assembler. You can correlate the assembler on this page with that in your .rst file.
Using this method you can generally debug your .c programs pretty successfully, although it can be laborious. Having said that I have found I have not had as many bugs/crashes as I expected if I take my time and test regularly and check-in to source control regularly.


Hope that is of some help to others, let's keep sharing ideas.




ervin

Thanks Lachlan.
That tip about the .rst files sounds brilliant.
I'll be trying it the moment I sit down for more SDCC dev!


AMSDOS

Quote from: mr_lou on 17:56, 05 July 15
Because the chapter isn't only about sprites. At the moment it also contains a drawSolidBox() function, and in time you might add more, like e.g. a drawCircle() or what do I know. General graphical stuff.
One might also argue that "drawTile" isn't about sprites either.


I would tend to agree based on the rules governed in the Firmware Manual which highlights "The Graphics VDU" & "The Screen Pack". Sprites are usually managed by the Screen Pack, which means they are represented as Encoded Bytes. A Graphic on the other hand deals in Graphic Pen Colours, so depending on what Mode your in, it could be anywhere from 2 to 8 bytes required to draw it.


Unfortunately there is also an argument that Sprites are nothing more than User Defined Graphics (UDG), which in that case is "The Text VDU" and then you've got a Loose Cannon in "The Graphics VDU" with "GRA WR CHAR (&BBFC)" aka TAG in BASIC, for positioning any character you want anywhere onscreen (except the Border). Because the Graphics VDU deals with this, they are essentially handled differently and you don't need to be worry about screen mapping.
"Jet-Boot Jack" is a nice example in how UDGs are used and the writers have only Sprites for Jack, which is kind of clever because the scenery is quite colourful, though in a way the writers have made Jack the focal point.  :D
* Using the old Amstrad Languages :D   * with 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

mr_lou

I'm getting this error on compiling now:
obj/main.asm:1401: Error: <a> machine specific addressing or addressing mode error

Line 1401 in main.asm says:
jr    00102$

I can see it's at the very end of my main loop. So I'm guessing it happens when it's trying to jump back and run the loop again. But why did this suddenly happen? And how do I fix it?



EDIT: Nevermind. I was calling cpct_waitVSYNC() twice in my loop, which hasnt' been a problem up until now, but now it is.

ervin

Quote from: mr_lou on 07:22, 12 July 15
I'm getting this error on compiling now:
obj/main.asm:1401: Error: <a> machine specific addressing or addressing mode error

Line 1401 in main.asm says:
jr    00102$

I can see it's at the very end of my main loop. So I'm guessing it happens when it's trying to jump back and run the loop again. But why did this suddenly happen? And how do I fix it?



EDIT: Nevermind. I was calling cpct_waitVSYNC() twice in my loop, which hasnt' been a problem up until now, but now it is.

I'd hazard a guess and say that your were trying to jump more than 128 bytes away with the JR.
I got the same error message when I did that.
:)

ronaldo

@mr_lou: I've never seen this problem happen on a C-based program. I've seen it happen when using inline assembler. It is SDCC related. Without having a look at your code, it's very difficult to know what may be causing this problem. As @ervin says, It might be a big loop and a bad size calculation by SDCC, which leads to using jr instruction on a more than 128-byte long jump.

Anyway, calling cpct_waitVSYNC() twice in a row has near to 0 effect with respect to calling it just once. The second call returns immediately as VSYNC is still active. If you wanted to wait for 2 VSYNCs, the propper way to do it would be this one:

cpct_waitVSYNC();
// Wait for 2 interrupts to ensure that VSYNC signal is again inactive until calling waitVSYNC for the second time.
_asm_("halt");
_asm_("halt");
cpct_waitVSYNC();

mr_lou

Quote from: ronaldo on 10:45, 12 July 15Anyway, calling cpct_waitVSYNC() twice in a row has near to 0 effect with respect to calling it just once. The second call returns immediately as VSYNC is still active.

Yes, I saw that. But I didn't do it like that either.
What I was doing was this:

drawSomeSprites();
waitVSYNC();
drawSomemoreSprites();
waitVSYNC();

That way I could get 25fps without any flickering. But the 2nd waitVSYNC() suddenly gave me this error. So I removed it.
The idea was that I could update 2 different parts of the game in each their own Vsync cycle.

I haven't written a line of assembler myself (yet) in this project. So it is a bit strange why the error occurs when I re-insert the 2nd waitVSYNC() again.

BUT... if I do this:

drawSomeSprites();
waitVSYNC();
drawSomemoreSprites();
drawSomemoreSprites(); // Doing exactly the same as above
drawSomemoreSprites(); // Doing exactly the same as above
waitVSYNC();

- then I don't get the error....

ronaldo

@mr_lou: It appears to be, as we were saying before, an SDCC calculation error. You may have a loop that takes exactly 128/129 bytes or similar, and SDCC is calculating it badly. Solutions:

       
  • Refactor your code so the loop becomes smaller (just 3/4 calls and the code placed in functions)
  • Add more code to the loop, to force SDCC calculating it correctly and using jp instead of jr.
You may submit your code as an issue to SDCC developers for their consideration.

Carnivius

This is neat.  I'll come back to this in a bit after working on my phone game (gotta pay bills and such).  Keep up the good work. :D
Favorite CPC games: Count Duckula 3, Oh Mummy Returns, RoboCop Resurrection, Tankbusters Afterlife

mr_lou

Quote from: Carnivac on 12:47, 13 July 15
This is neat.  I'll come back to this in a bit after working on my phone game (gotta pay bills and such).  Keep up the good work. :D

...a phone game pays the bills?
I did not know that....

(Referring to my Pirate Diamonds which absolutely does not pay any bills whatsoever.  ;) )

mr_lou

@ronaldo

Why can't I add a simple function like this, with assembler?


void myTest(u8 test) {
  test;
  __asm
  ld a, (ix + 4)
  __endasm;
}


Very simple. Does nothing in fact.

But compiler gives error:
obj/main.asm:156: Error: <q> missing or improper operators, terminators, or delimiters

Line 156 says:     ld a, (ix + 4)

Now. I know from previously SDCC examples, that SDCC is supposed to insert the following code automatically:

    push    ix
    ld    ix,#0
    add    ix,sp


That doesn't seem to happen here? Maybe that's the reason?

ervin

Quote from: mr_lou on 14:13, 13 July 15
@ronaldo

Why can't I add a simple function like this, with assembler?


void myTest(u8 test) {
  test;
  __asm
  ld a, (ix + 4)
  __endasm;
}


Very simple. Does nothing in fact.

But compiler gives error:
obj/main.asm:156: Error: <q> missing or improper operators, terminators, or delimiters

Line 156 says:     ld a, (ix + 4)

Now. I know from previously SDCC examples, that SDCC is supposed to insert the following code automatically:

    push    ix
    ld    ix,#0
    add    ix,sp


That doesn't seem to happen here? Maybe that's the reason?

IX syntax seems to be a little different in SDCC.

Try this:


void myTest(u8 test) {
  test;
  __asm
  ld a,4(ix)
  __endasm;
}


mr_lou

Wott?!

Ok...

Going back to the one I was really trying to use then: (from way back in 2011)


void poke(u16 addr) {
addr;
__asm
  ld h,5(ix)
  ld l,4(ix)
  ld (hl),255
__endasm;
}


obj/main.asm:158: Error: <a> machine specific addressing or addressing mode error

Line 158 says:     ld h,5(ix)

Can you crack that one too then?  :)


EDIT/ADDED:

Ok, adding a '#' infront of the number makes it compile


void poke(u16 addr) {
addr;
__asm
  ld h,5(ix)
  ld l,4(ix)
  ld (hl),#255
__endasm;


However, it still doesn't work. It doesn't set the value 255 on the address that I give it. And it looks like it's the ld h,5(ix) and ld l,4(ix) that is the problem, because if I do this:

void poke(u16 addr) {
addr;
__asm
  ld h,#0xc0
  ld l,#0x00
  ld (hl),#255
__endasm;

Then it does work - but of course only on that one static address 0xc000


FloppySoftware

Quote from: mr_lou on 14:13, 13 July 15
Why can't I add a simple function like this, with assembler?


void myTest(u8 test) {
  test;     <----- What's the purpose of this?
  __asm
  ld a, (ix + 4)
  __endasm;
}


What's the purpose of the indicated fragment of code?
floppysoftware.es < NEW URL!!!
cpm-connections.blogspot.com.es

Powered by SMFPacks Menu Editor Mod