In case anybody is interested here's a video of the progress I have made on my game:
The sprite doesn't disappear when playing without the video encoding. Don't know why its doing that. The sound is out of sync too for some reason. Don't know why I can't get it working properly, sometimes it does, most the time it doesn't.
I have changed the tilemaps from 8x8 using the tilemap functions to display them, to 16x16 using the sprite functions. This has freed up a bit of memory (each screen takes up 1/4 of the space). But there is now more memory used by the tiles. I have got sound fx working, music on the title screen (not shown as its not ready to be unveiled yet). I will need to figure out compression as there will not be enough memory for 64 screens, multiple enemy sprites and all the associated code and puzzles. I want the game to be run in 64K, on a bare bones 464.
There is a map top-right which shows where you are and where you have been. There are enemies coded but not used on this build. I will show them on the next preview.
There is a basic puzzle, you cannot go north without the torch. Well, you can, but you are likely to get very lost. So you find the torch, then you can go north, and collect the three jewels. The jewels reappear though. The torch does not, but its not optimal how I have done it. I need to figure out how to stop them reappearing then I can use the same routine for the torch (and other collectables).
I will keep updating this topic with progress.
It's looking really good.
Looks quite responsive and nippy.
If you need any help with compression, yell out.
I've used exomizer a *lot* over the last few years, and had great results with it.
Just confirming... you're using cpctelera?
It looks really cool! I will play it for sure if you finish it :)
Not a fan of this kind of games, but I'd lie if I said it doesn't look really pretty!
That looks extremely good.
Cannot wait to try it.
NES Killer!
Thanks for the comments.
@ervin (http://www.cpcwiki.eu/forum/index.php?action=profile;u=82) yes I'm using CPCtelera. I've almost completely ran out of memory though. It was going way past 0xB000 and wouldn't load. I had to comment out a lot of stuff to make everything fit. Now It goes up to around 0xA300. The map is 64x16x10 which equals 10240 bytes (0x2800). So, to free up memory I put it at 0x1000 (the audio resides at 0x3818) and for some reason, although it should fit, it keeps coming up with overwrite warnings when I compile. The title screen displays and the music plays (which is what I assume would have been overwritten), but the game crashes when started.
I'm also having flicker problems with the main sprite. It's even more obvious on a real CPC.
There are many ways to optimize your map. One thing could be to load areas from the disk (mandatory for big games).
Also, instead of having a simple array for each room, you could:
- Specify one tile to fill the background.
- Have a list of positions for specific elements, such as the trees (stores the X/Y of each trees in a list).
- For more geometrical areas such as your dungeons, have little system of horizontal/vertical lines, storing only the origin, the direction, the length, and the tile to repeat.
With such system, a full room could be encoded in a few dozen of bytes.
You can disable the firmware, and also move the stack pointer, to get the maximum amount of free RAM.
#define NEW_STACK (void*)0xC000-64
cpct_disableFirmware();
cpct_setStackLocation(NEW_STACK);
I've put the stack 64 bytes below 0xC000, and I allow for 64 bytes movement up or down.
Therefore I'm allowing my program to use RAM all the way up to 0xC000-128 = 0xBF80.
That's a lot of extra RAM, and, as Targhan suggested above, there are many things that can be done to shrink your room definitions.
I wrote a tile-based scrolling engine a couple of years ago, and I didn't store all the tile references for a screen.
I simply stored the X/Y position of each object into a simple array.
Then each object has its own tile reference list.
This way, if you have 4 copies of an object on the screen, you simply have 4 sets of objectID,X,Y in the room definition (for that objectID).
Then when you are drawing the screen, you use the objectID to access a table of objects and their tile references.
It helps to think of it all as a database.
Also, exomizer.
8)
@Targhan (http://www.cpcwiki.eu/forum/index.php?action=profile;u=110) sounds complicated. I'm not very good at that sort of thing. Also due to the way the engine works, I don't think it will be suitable without a complete re-write. Its a miracle what I have done is working.
@ervin (http://www.cpcwiki.eu/forum/index.php?action=profile;u=82) I already have firmware disabled but the problem is loading in something from BASIC that overwrites the part of the firmware that deals with loading.
Quote from: EgoTrip on 13:59, 11 November 15
@Targhan (http://www.cpcwiki.eu/forum/index.php?action=profile;u=110) sounds complicated. I'm not very good at that sort of thing. Also due to the way the engine works, I don't think it will be suitable without a complete re-write. Its a miracle what I have done is working.
@ervin (http://www.cpcwiki.eu/forum/index.php?action=profile;u=82) I already have firmware disabled but the problem is loading in something from BASIC that overwrites the part of the firmware that deals with loading.
@EgoTrip (http://www.cpcwiki.eu/forum/index.php?action=profile;u=337): pm or e-mail me the source and I'll happily take a look and see what can be done. If I sort it out I'll explain what I did and why :)
If you're loading from BASIC and the file is too big there are two choices.
1. split it up. Load part into main ram, part into screen and in the loader join them together
2. load the data really low (e.g. 0x0040) and then copy into it's final location.
Quote from: EgoTrip on 13:59, 11 November 15
@Targhan (http://www.cpcwiki.eu/forum/index.php?action=profile;u=110) sounds complicated. I'm not very good at that sort of thing. Also due to the way the engine works, I don't think it will be suitable without a complete re-write. Its a miracle what I have done is working.
@ervin (http://www.cpcwiki.eu/forum/index.php?action=profile;u=82) I already have firmware disabled but the problem is loading in something from BASIC that overwrites the part of the firmware that deals with loading.
@EgoTrip (http://www.cpcwiki.eu/forum/index.php?action=profile;u=337): you're doing great and result is good.
Targhan suggested a good simple method which is to make 1 map for each screen. You then store each of these screens on the disc as a seperate file. Now in your code you need to know, if you move to the left, right, up or down, which screen is next to load.
Then when you do that movement, load the screen and display it. The code has space for 1 screen at a time and you load each new one into this area.
The easiest thing is to keep firmware active so that you can load the screens using the firmware disc routines.
I am not sure how easy it is to manage separate files with cpctelera.
EDIT: The complication here is anything that can be picked up/dropped, or any obstacle/puzzle that must be completed.
In this case you need to remember the location of each item seperately from the files for the screens. You must also remember which puzzles you completed.
But then again you need to remember this if the game is re-started? So this data should be stored seperately.
e.g. jewel, x,y, screen, collected?
@ronaldo (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1227): Does cpctelera allow management of separate files?
@ronaldo (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1227): Does cpctelera allow you to define a loader program which can load seperate parts and join them if necessary?
Quote from: arnoldemu on 14:36, 11 November 15
@EgoTrip (http://www.cpcwiki.eu/forum/index.php?action=profile;u=337): you're doing great and result is good.
Targhan suggested a good simple method which is to make 1 map for each screen. You then store each of these screens on the disc as a seperate file. Now in your code you need to know, if you move to the left, right, up or down, which screen is next to load.
Then when you do that movement, load the screen and display it. The code has space for 1 screen at a time and you load each new one into this area.
The easiest thing is to keep firmware active so that you can load the screens using the firmware disc routines.
I am not sure how easy it is to manage separate files with cpctelera.
EDIT: The complication here is anything that can be picked up/dropped, or any obstacle/puzzle that must be completed.
In this case you need to remember the location of each item seperately from the files for the screens. You must also remember which puzzles you completed.
But then again you need to remember this if the game is re-started? So this data should be stored seperately.
e.g. jewel, x,y, screen, collected?
There are other ways to deal with this without using disk.
For example, if a screen is 16x10 (and you have 64 screens, if I understand correctly what @EgoTrip (http://www.cpcwiki.eu/forum/index.php?action=profile;u=337) said), then you can have 160 bytes to put the working screen and compress each screen individually. Then when you change screen, you uncompress into those 160 bytes (that's what Space Pest Control does, each screen is 100 bytes that is compressed to ~60% of that).
Also you could define the screens in a more smarter way (as other mentioned already) so they use less memory.
Then your problem is remembering state (object x was collected). Well, that's easy! If you identify each object with one unique ID (say 1 byte), you only need an array as large as the number of objects.
In Space Pest Control I can handle 8 persistent objects per screen, meaning that I can save that information with just 1 byte per screen ;)
I know it sounds like adding limitations to your design, but that's about it when you're dealing with very low resources.
EDIT: sorry, the persistence part could be more complicated than that, it all depends how you currently store your data. I just hope this may give you ideas!
What I proposed is not complicated at all, don't worry, and I'm pretty sure you HAVE to do something like that, else you won't be able to finish your game.
What I talked about is just how to encode each room in a specific, compressed format. When you enter the room, you decompress it into an uncompressed array composed of raw tiles, your engine already work with. So nothing changes in your engine: only a small work to do when entering a room.
Great work and looking good!
Out of interest, was this idea originally planned to be created with Arcade Game Designer on the CPC?
Quote from: sigh on 20:35, 11 November 15
Great work and looking good!
Out of interest, was this idea originally planned to be created with Arcade Game Designer on the CPC?
Sort of. I did a limited prototype version of the game for the Spectrum in AGD: New Game: A Prelude to Chaos - World of Spectrum (http://www.worldofspectrum.org/forums/discussion/50028/new-game-a-prelude-to-chaos) But I had problems porting it over to the CPC version due to bugs in AGD. It is also missing quite a few things I want to include that AGD is too limited for. Besides, I always wanted the game to be in MODE 1. AGD only does MODE 0.
@EgoTrip (http://www.cpcwiki.eu/forum/index.php?action=profile;u=337): I have looked at the source.
First in the config file set the start to 0x0040.
This is the lowest that is ok.
Z80CODELOC := 0x0040
Then I removed all the __at to put all the data together.
I built and it came to 25K.
code ends around 6B00. You have another 15K to go :)
When you reach that limit there is more that can be done. :)
What about the music? That has to be where it was located or it wont work. I could always recompile the bin files but its hard to know where it will reside in memory so its easier to put it below &4000. Also according to the documentation, some routines can't be used below &4000 which is why I started the code there.
Quote from: EgoTrip on 23:26, 11 November 15
What about the music? That has to be where it was located or it wont work. I could always recompile the bin files but its hard to know where it will reside in memory so its easier to put it below &4000. Also according to the documentation, some routines can't be used below &4000 which is why I started the code there.
In RUNCPC, I had all my data located below 0x4000 (music, exomized sprites, lookup tables etc), and all my code above 0x4000.
It worked great.
Quote from: EgoTrip on 23:26, 11 November 15
What about the music? That has to be where it was located or it wont work. I could always recompile the bin files but its hard to know where it will reside in memory so its easier to put it below &4000. Also according to the documentation, some routines can't be used below &4000 which is why I started the code there.
good point.
I'll re-arrange it tonight and get back to you.
I'm going to do as ervin suggests and locate all of the data below &4000.
So how do I get the data below 0x4000 without "overlap record detected" errors showing up and the game being corrupted?
Maybe you can load a binary there?
I found a way but it's not cpctelera compatible. So I need ronaldo's help.
There are two things that can be done:
- Set the location of the run time data (_DATA section in cpctelera/sdcc speak). Yours is small so doesn't make much difference. This can't be defined in cpctelera.
- Use the following at the top of each c file to control where the data goes.
Replace CONSTDAT with a short (8 letter max) name.
#pragma constseg CONSTDAT
- in C there are "sections". These contain data and/or code. You can use the #pragma to name a section. The purpose of sections is to organise. You can then define where in memory the section begins. All c files with the same section are grouped together. Normally there is _CODE and _DATA. and data is put after _CODE. There are others, but ignore them they are not important here.
In my separate linker script I have this (cpctelera doesn't use linker scripts):
-b _CONSTDAT=0x0040
That moves all the data defined with const u8.
You can still have your music located at the absolute location. :)
To manage this you will need to move data from one file to another to split them up and control which section they are grouped in.
To avoid the error, look at the .map file. In the obj directory.
it looks like this:
00000000 s__DABS
00000040 s__CONSTDAT
00000047 l__INITIALIZED
00000047 l__INITIALIZER
000000CF l__DATA
0000293C l__CODE
00003EC0 l__CONSTDAT
00004000 s__CODE
0000693C s__DATA
00006A0B s__INITIALIZED
00006A52 s__GSFINAL
00006A52 s__GSINIT
00006A52 s__HOME
00006A52 s__INITIALIZER
The s__ prefix is the *start*. The l__ prefix is the length. From this you can know how long each section is, where it starts and then you
In this s__CODE is start of code "section".
I will talk with ronaldo about the best way to make this easy for users to control.
You can tell cpctelera precisely where to put data.
In RUNCPC, I have the following DEFINEs in define.h:
#define ADDR_FRAME_BUFFER 0x0100
#define ADDR_SCREEN_BUFFER 0x0500
#define ADDR_BACK_BUFFER 0x0900
#define ADDR_AUDIO 0x0d00 // 256
#define ADDR_SPRITE 0x0e00 // 5888 (allow for 5667+140=5807)
#define ADDR_T_SIZE 0x2500 // 128
#define ADDR_G_PALETTE 0x2580 // 16
#define ADDR_TILEBANK 0x2590 // 512
#define ADDR_EXO_BUFFER 0x2790 // 0x4f20-0x2790=10128
Then I have another file called global.h.
It contains things like:
__at(ADDR_FRAME_BUFFER) u8 FRAME_BUFFER[1024];
__at(ADDR_SCREEN_BUFFER) u8 SCREEN_BUFFER[1024];
__at(ADDR_BACK_BUFFER) u8 BACK_BUFFER[1024];
__at(ADDR_AUDIO) u8 AUDIO_BUFFER[1280];
__at(ADDR_SPRITE) u8 SPRITE_BUFFER[5888];
__at(ADDR_G_PALETTE) u8 const g_palette[16]={
0x00, // black
0x01, // blue
0x02, // brightBlue
0x03, // red
0x04, // magenta
0x05, // mauve
0x06, // brightRed
0x09, // green
0x0b, // skyBlue
0x0d, // white
0x0f, // orange
0x12, // brightGreen
0x18, // brightYellow
0x1a, // brightWhite
0x07, // purple
0x0c, // yellow
};
@ervin (http://www.cpcwiki.eu/forum/index.php?action=profile;u=82): Yes you can. That requires exact knowledge of the length of the data and is hard to maintain if it changes size.
I know that EgoTrip already uses this to set the location of the music.
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 ;) ).
Thanks for the replies, I will see how it goes and let you know when I run into problems.
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.
I'd be very happy to have a look at your code, if you like.
Maybe we can figure out what is going wrong.
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.
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.
Quote from: EgoTrip on 13:00, 16 November 15
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.
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.
@Targhan (http://www.cpcwiki.eu/forum/index.php?action=profile;u=110): 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.
:)
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 (http://www.cpcwiki.eu/forum/index.php?action=profile;u=110) 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.
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 (http://www.cpcwiki.eu/forum/index.php?action=profile;u=337) and everybody having this problems:
Quote from: EgoTripSo 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).
Quote from: arnoldemuDoes 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.
Quote from: arnoldemuDoes 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.
Quote from: arnoldemuIt 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.
Quote from: arnoldemuBut 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.
Quotethe 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.
Quote from: ronaldo on 21:33, 16 November 15
It depends on what you mean with "management of separate files". Latest versions of CPCtelera (http://lronaldo.github.io/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.
Quote from: ronaldo on 21:33, 16 November 15
- You can create your own loader program and place it in the folder of included files. Then CPCtelera (http://lronaldo.github.io/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
Quote from: ronaldo on 21:33, 16 November 15
- 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.
Quote from: ronaldo on 21:33, 16 November 15
- 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 (http://www.cpcwiki.eu/forum/index.php?action=profile;u=110) 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 :(
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.
Quote from: EgoTrip on 17:59, 18 November 15
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.
How do I load something at 0x0040 then call it?
Quote from: EgoTrip on 18:54, 18 November 15
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.
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?
Quote from: EgoTrip on 20:01, 18 November 15
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.
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.
Quote from: EgoTrip on 19:18, 26 November 15
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.
How do I do that with CPCtelera?
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.
Nice work, man :). Hope we can help you learn to optimize it a little further so you can achieve your goals for this game :D.
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 (http://www.cpcwiki.eu/forum/index.php?action=profile;u=17) 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.
Quote from: EgoTrip on 11:49, 30 November 15
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).
@Executioner (http://www.cpcwiki.eu/forum/index.php?action=profile;u=17): 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.
Quote from: ronaldo on 22:10, 30 November 15
@Executioner (http://www.cpcwiki.eu/forum/index.php?action=profile;u=17): That's a good idea. Do you know of a way of doing it without using a custom interrupt handler to count interrupts?
I'm surprised you don't use your own custom interrupt handler anyway, but there is a variable in firmware memory (#B8BF on a 6128, #B192 on a 464) which keeps a count 6-1. It's not necessarily aligned with the frame flyback, but it could be made to be by setting it on VSYNC. When the CPC is started, this variable counts 256 frames before it gets reset to 6. If you set it to 6 on VSYNC, you can test it every interrupt and when it gets to 1 (or maybe 2) you'll be at the correct interrupt. The hard bit is determining whether to use #B8BF or #B192.
@Executioner (http://www.cpcwiki.eu/forum/index.php?action=profile;u=17): That may be a good way to do it, but it requires firmware being enabled. I was talking about doing it without firmware: the low-level library of CPCtelera (http://lronaldo.github.io/cpctelera) is designed to be used without firmware running.
CPCtelera (http://lronaldo.github.io/cpctelera) is designed to be a low-level library for programmer needs (along with a development framework based on standard GNU tools). It does not use an interrupt handler, because I think that should be up to the user. CPCtelera (http://lronaldo.github.io/cpctelera) should not execute any kind of code by itself: everything should be up to the programmer.
However, I may create kind of a default interrupt handler for these matters, and leave the programmer the option to set it up at will.
That way a CPCTelera program could run under all OS for the CPC. :)
Quote from: ronaldo on 22:44, 30 November 15
However, I may create kind of a default interrupt handler for these matters, and leave the programmer the option to set it up at will.
I don't actually know very much about CPCTelera having never used it. I don't have much use for C seeing as I prefer writing assembler, but if you're not using the firmware and lower ROM is enabled, it should be pretty easy to create a standard interrupt handler (perhaps with hooks to extend it to do the other stuff like keyboard scanning etc). It's a pitty we can't read the Vertical Character count in the CRTC really, would make interrupt handlers much simpler.
Quote from: Executioner on 06:11, 01 December 15
I don't actually know very much about CPCTelera having never used it. I don't have much use for C seeing as I prefer writing assembler...
One of the interesting things with
CPCtelera (http://lronaldo.github.io/cpctelera) is that it lets you program in C or Assembler. It can be used as framework + low-level library, or only as a framework for creating projects and building them. You can develop any kind of software. If you do not use the low-level library, it acts only as a way os simplifying management tasks: you write your .asm or .c (or even both) code, tape in
make, and you have binary, dsk and cdt files created :) .
And yes, creating a standard interrupt handler is pretty easy. The issue for me is not creating the handler, but providing it to other programmers as a service they can use or not in their programs. I invest most of my time in documenting and designing APIs and interfaces in the hope of making them easy and practical to use.
Thank you very much for your views and suggestions: they are going to be useful, for sure :D .
Quote from: ronaldo on 22:10, 30 November 15
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.
z80 opcode:
HALT
;)
The code to keep track of interrupts within a frame was explained superbly by Fano some time ago.
You can check that here (with source code) Frame Timings (http://www.cpcwiki.eu/forum/programming/frame-timings/msg62034/#msg62034)
Done a lot of optimising, coded in a boss, sorted puzzzles out. Everything looks and works a lot better now but theres still a few issues that need fixing.
But, my laptop died today so there will be little/no progress until I get a new one. Which will probably be never the way things are.
I just finished Oceano (uploading on yt), what a great game!
Can't wait for this!!!
Quote from: VincentGR on 18:18, 14 December 15
I just finished Oceano (uploading on yt), what a great game!
Can't wait for this!!!
Thanks. But as I just said theres going to be quite a delay until I am able to do more work on it. So you'll have a bit of a wait on your hands.
Quote from: EgoTrip on 18:38, 14 December 15
Thanks. But as I just said theres going to be quite a delay until I am able to do more work on it. So you'll have a bit of a wait on your hands.
Take your time mate, I am just excited.
In the meantime theres more stuff here:
EgoTrip's Stuff: All My Productions In One Post (http://egochip.blogspot.co.uk/2015/01/all-my-productions-in-one-post.html)