EgoTrip's Game Progress Topic

[EgoTrip]

Thanks for the replies, I will see how it goes and let you know when I run into problems.

[EgoTrip]

Nope it wont work. I put all the data that I put in an absolute location in its own file, still get loads of stupid overload record detected errors. I guess the only thing left is to waste memory writing my own text printing routine using tiles, then I will be able to start the code at the bottom of memory. Only I don't know how to write a routine. All this time wasted on this bullshit when I could be working on the game, but I can't do anything more until I can use the memory under &4000.

[ervin]

I'd be very happy to have a look at your code, if you like.
Maybe we can figure out what is going wrong.

[arnoldemu]

I sent a message to ronaldo.

It is crazy having to put everything at absolute addresses all the time - it makes it too hard for beginner programmers.

In fact, I think the music doesn't need to be at an absolute address.
It's all crazy.

He hasn't responded yet.

[EgoTrip]

The music DOES need to be at an absolute address, that is an Arkos player requirement. The code it generates is not relocatable but you can always re-export the code. However knowing where to put it is the problem which is why I put it at a fixed location below the start of the code.

I've tried to write a text routine using tiles but I've got myself confused along the way with pointers and arrays and stuff. It should work in theory similarly to the tile map but it is not in one long block and each text message has a different length to save memory. However if I can't figure it out then I'm just going to go into a long block like the tile map and adapt that same routine. I need to do this so I can put the start of the code down to around 0x2000 so I can fit everything in and have the audio below that.

[arnoldemu]

The music DOES need to be at an absolute address, that is an Arkos player requirement.

I've made some code to take away that requirement
It's not cpctelera compatible yet.

[Targhan]

Yes, Arkos Tracker music (or actually, any music from any generic player) needs to be statically located. This is required for optimizations.
However, I don't really see what the problem is. Music do no "grow" like code or graphics can. What about loading it at the bottom or at the top of the memory, reserve an amount of bytes that seem fair (biggest music I ever composed was 8-9kb)? Set your limit and ask the musician to live with that, everything should be all right.

[arnoldemu]

@Targhan: There is no problem. When programming in C it is often easier to allow data and graphics to be located automatically by the linker. In the programming section i proposed a method where the location of the data can be controlled by the linker, then the code "fixes" it in place making it static. This would be a perfect way to automatically manage it.

In the main function, the programmer would call the function giving it the location of the data, when the data is compiled at 0, I can go through and add the location on to make it static.

There is a similar relocate function for starkos musics I believe that Tom et Jerry made.

Music can change size during development, when a new tune is added, or a tune is modified, this allows music development to be done in parallel to code development and to not worry about where in ram it is located.

[EgoTrip]

I've written my own text routine which works, and located all the data from 0x0040 onwards and everything fits now with around 8k left.

@Targhan I did that and it worked, the problem was trying to put other data below it, it kept coming up with overwrite errors even tho there was more than enough space. But I worked around it now. It wasn't an Arkos problem it was a CPCtelera problem.

[ronaldo]

Hi all:

   Sorry for taking so long to reply. My workload past 16 days has been 120% and was impossible for me to do anything that wasn't finising my dissertation, in order to submit in on time for revision. That required living like a recluse these days, as every hour was gold for me.

   I'll try to answer your questions as detailed as possible, to try to help @EgoTrip and everybody having this problems:

So how do I get the data below 0x4000 without "overlap record detected" errors showing up and the game being corrupted?

   
• Overlapped records occur when 2 streams of bytes are trying to be located at the same place in memory. That's clearly impossible, and SDCC issues a warning for that, because SDCC is just following instructions, and cannot change programmer's orders. In your case, @EgoTrip, this is what was happening to you:
  [attach=2]
  Binary files are streams of consecutive bytes. The compiler (SDCC in this case) produces just one binary file, thought to be loaded at a concrete place in memory. If you try to "insert" bytes inside the already produce binary space, you end up with overlapping records. In this case, your binary starts at 0x1000: locations from 0x3818 to the end of music are part of the binary space. You cannot place there part of the binary generated and the music at the same time. When you are locating things statically using __at, you are responsible for not putting them in the place where other parts of the binary lay. For instance, you may put the music at 0x040, then place the start of the binary where music ends using Z80CODELOC=0x2000 (replacing 0x2000 by the place where music ends).

Does cpctelera allow management of separate files?

   
• It depends on what you mean with "management of separate files". Latest versions of CPCtelera can include files from a given folder into the final DSK. So, you can put some files with graphics, data or whatever, and they are automatically added to the DSK after compiling. You also can include binary files by just adding them to the source folder with the .bin extension. These files are automatically converted to a C-array in an equivalent .c source file, and compiled+added to the project automatically.

Does cpctelera allow you to define a loader program which can load seperate parts and join them if necessary?

   
• You can create your own loader program and place it in the folder of included files. Then CPCtelera will automatically add it to your DSK file. You can do this with a BASIC loader easily. If you want to create a more advanced loader, you may create a separate proyect for the loader and add a line to your makefile to automatically copy it to the folder of included files. If anyone of you want to do this and don't know how, I can create an example to show you how.

It is crazy having to put everything at absolute addresses all the time - it makes it too hard for beginner programmers

   
• I agree in that this is hard for beginners, but there is no need to magnify this problem. The only thing that requires to be located at a static address is the music. There is no need to put "everything" at an static address. I'm really keen on making things as useful and versatile as possible, but there always will be 2 things to keep in mind: 1) while things evolve, there always be some parts more difficult to manage than others, 2) whenever someone wants to optimize or have greater control of parts of the program, knowledge of the architecture and memory layout is essential. That's not any kind of "fault", it is a feature of the low-level programming world.

But I think for const data it would be great if cpctelera allowed you to locate it where you want and you can set
  it and forget it (well almost as easy as that )

   
• I agree with you in this. In fact, there is a point in my task list specifically for this problem. There is a quick-and-dirty solution using a command line tool @Targhan made for relocating song data. Including some detection and call to this tool on makefiles would do the trick. I'll have to take a look at this possibility along with other proposed solutions. While these things evolve (which takes time), the easier way to manage this is by placing music at 0x040 and Z80CODELOC at the end of music. That's a little bit uncomfortable, but not so hard once you know it.

I'll try to help as much as possible with problems like these but, please, allow me some time to recompose myself. My available time for CPC-related things has been -1 past weeks and will be close to 0 next days until I get up to date again.

[EgoTrip]

the easier way to manage this is by placing music at 0x040 and Z80CODELOC at the end of music.

That's exactly what I did. The main issue I had was that I was using the text routine, which needed to be located above 0x4000. In the end I just wrote my own with a custom tile map font.

Now everything fits fine and I'm able to get on with the actual game, which is coming along nicely. I may have a new video to show in the next couple of days. Thanks for you help.

[arnoldemu]

It depends on what you mean with "management of separate files". Latest versions of CPCtelera can include files from a given folder into the final DSK. So, you can put some files with graphics, data or whatever, and they are automatically added to the DSK after compiling. You also can include binary files by just adding them to the source folder with the .bin extension. These files are automatically converted to a C-array in an equivalent .c source file, and compiled+added to the project automatically.

Exactly this.

A directory to put a collection of files (loader, title screen, main code, extra level data) and this is added to the dsk automatically. It is not linked into the program.

But also, a directory where you put data that *is* linked in.

Suggestion for the future: For cdt releases, a way to define the order of these files for putting into the cdt.

   
• You can create your own loader program and place it in the folder of included files. Then CPCtelera will automatically add it to your DSK file. You can do this with a BASIC loader easily. If you want to create a more advanced loader, you may create a separate proyect for the loader and add a line to your makefile to automatically copy it to the folder of included files. If anyone of you want to do this and don't know how, I can create an example to show you how.

perfect.
I have some code for loading data files that uses the firmware. If CPCtelera doesn't have this yet I am happy for you to use it so that people may use it to load additional data (e.g. level data) into their programs easily

   
• I agree in that this is hard for beginners, but there is no need to magnify this problem. The only thing that requires to be located at a static address is the music. There is no need to put "everything" at an static address. I'm really keen on making things as useful and versatile as possible, but there always will be 2 things to keep in mind: 1) while things evolve, there always be some parts more difficult to manage than others, 2) whenever someone wants to optimize or have greater control of parts of the program, knowledge of the architecture and memory layout is essential. That's not any kind of "fault", it is a feature of the low-level programming world.

Yes I did get carried away and magnify the problem. I think because EgoTrip got frustrated that is why I magnified it a little, more to bring it to attention so it can be thought about and addressed in the future
I know that to get the best out of the cpc the programmer must have a good knowledge of the low-level memory layout. That comes with experience.

   
• I agree with you in this. In fact, there is a point in my task list specifically for this problem. There is a quick-and-dirty solution using a command line tool @Targhan made for relocating song data. Including some detection and call to this tool on makefiles would do the trick. I'll have to take a look at this possibility along with other proposed solutions. While these things evolve (which takes time), the easier way to manage this is by placing music at 0x040 and Z80CODELOC at the end of music. That's a little bit uncomfortable, but not so hard once you know it.

great. I also have a compile time solution but mine takes these steps:
1. compile data
2. link data
3. look in map file to find address it was located at
4. re-compile the data at new address
5. inject data into binary.
It works but it's not clean

[EgoTrip]

New problem.

I want to load my HUD in as a part of the loading screen and have it there all the time. But when I run the game it clears the screen. How do I stop it? There is nothing in the code that clears the entire screen, just routines to clear certain areas.

[arnoldemu]

New problem.

I want to load my HUD in as a part of the loading screen and have it there all the time. But when I run the game it clears the screen. How do I stop it? There is nothing in the code that clears the entire screen, just routines to clear certain areas.

In your loader that loads the hud and starts the game...

Is the main part using RUN or LOAD then CALL?
If RUN, change to load and call.

[EgoTrip]

How do I load something at 0x0040 then call it?

[arnoldemu]

How do I load something at 0x0040 then call it?

You can't with basic. need to be an assembler based loader.

Attached is an asm file. Build with pasmo:

pasmo --amsdos egoload.asm egoload.bin

Files should be named ego.bi0, ego.bi1 etc
ego.bi0 for the hud
ego.bi1 for the code

You will need to change the palette.

Download pasmo from here:

http://pasmo.speccy.org/pasmodoc.html


EDIT: Run will load the program, re-initialise the firmware and execute it. This means clearing the screen, setting the default palette, changing the mode that kind of thing. LOADing and CALLing stops this. For programs below &383 you have to use an assembler based loader.

[EgoTrip]

Is there another way? I can't be bothered with messing around installing even more stuff. Sorry don't mean to sound ungrateful or anything but can't it just be done in WinAPE assembler?

[arnoldemu]

Is there another way? I can't be bothered with messing around installing even more stuff. Sorry don't mean to sound ungrateful or anything but can't it just be done in WinAPE assembler?

I will try it tomorrow.

[EgoTrip]

I've been working on this quite a bit lately and have done a lot of code and graphics optimising, and have managed to shrink everything down to fit. I had to ditch some graphics though. Most of the engine is done now, theres still a few more things that I need to figure out like pushable blocks. Hopefully I have enough space left to put in the routines.

The main issue I have now though is flicker. It's not as bad as the video exaggerates it, but its still unacceptable. How do I fix it? Amy disappears completely at times near the bottom of the screen.

[Executioner]

The main issue I have now though is flicker. It's not as bad as the video exaggerates it, but its still unacceptable. How do I fix it? Amy disappears completely at times near the bottom of the screen.

How many sprites are you erasing and drawing maximum? You may need to do the erase/draw routines on interrupt 4 or 5 of the frame, so you start erasing them all around the last scan lines of the screen, or (if you had any memory left) use a double buffer or erase/draw/blit scratch area.

[EgoTrip]

How do I do that with CPCtelera?

[EgoTrip]

So I managed to free up around 4k. I knew my code needed optimising but I didn't realise just how much memory multiplication and division took up, so pre-calculating things that need to be tested more than once into a variable and using that did wonders. I also managed to reduce flicker to almost zero by moving the wait vsync function from the start of the event to just before the drawing takes place. I still get a bit of flicker from enemies if the maximum is on screen but its nowhere near as bad now.

I have used some of the memory gained to code in other features such as item drops, energy and power bars, and some other little things. I don't want to give away too much to spoil the game when its finished. There will be a new video some point this week, depending on how things go.

[ronaldo]

Nice work, man . Hope we can help you learn to optimize it a little further so you can achieve your goals for this game .

Regarding flickering, another thing you can do is not moving all enemies each frame. If you have 8 enemies, you can move 4 of them on even frames and the other 4 on odd frames. That will save you some drawing time and improve framerate. Other more complex things may be have your sprites ordered by y-coordinate to draw upper ones first, or do drawing on interrupts as @Executioner suggested. However, I'd advise on testing ideas one by one and allocating enough time for understanding and mastering them. As you already know, this sort of programming has lots of details that can be stressing and frustrating.

[Executioner]

I also managed to reduce flicker to almost zero by moving the wait vsync function from the start of the event to just before the drawing takes place. I still get a bit of flicker from enemies if the maximum is on screen but its nowhere near as bad now.

Sounds like CPCTelera could benefit from a waitInt(n) function (the nth interrupt after the VSYNC), so you can give yourself a few more scan lines to work with (if VSYNC is Int 0, you can start erasing/drawing after Int 5 perhaps, giving you about 3000 more cycles time).

[ronaldo]

@Executioner: That's a good idea. Do you know of a way of doing it without using a custom interrupt handler to count interrupts?

I can easily code a wait4NextInterrupt function, but I'm unsure about how to know if next interrupt is 4th or 5th without counting them.