Some Graphic Coding & Audio help.
Hello my fellow WoS'ers
I am in the process of writing some code for graphical purposes - I have Z88DK raring to go but I do not know how to take bytes from a memory file and put them on the screen, well I know how to shift bytes but I do not know where they go in regards to the +3 memory area(s).
I have some ideas for pixel shifting and animation that I would like to explore - but would need a quick guide / how to if there is such a link or friendly coder out there (C is preferred but I can do *little* asm).
Secondly are there any tracker / writing programs for the PC (Win7 compatible) that would allow me to write / experiment with AY-Synth - with a view to porting these AY-Mods, if you will, to the Spectrum?
I am attempting to write a small graphical adventure game for the +3e environment from scratch so that I can learn drawing routines, perhaps starting in C and then to ASM - the latter is the true goal, perhaps only using C as a wrapper for the ASM in the long run. The game would based on the 8bit/16bit IDE hard disk device so graphical / audio size is not an issue and would be loaded when required.
So any hints / tips / books recommended would be an absolute treasure - thanks for reading
I am in the process of writing some code for graphical purposes - I have Z88DK raring to go but I do not know how to take bytes from a memory file and put them on the screen, well I know how to shift bytes but I do not know where they go in regards to the +3 memory area(s).
I have some ideas for pixel shifting and animation that I would like to explore - but would need a quick guide / how to if there is such a link or friendly coder out there (C is preferred but I can do *little* asm).
Secondly are there any tracker / writing programs for the PC (Win7 compatible) that would allow me to write / experiment with AY-Synth - with a view to porting these AY-Mods, if you will, to the Spectrum?
I am attempting to write a small graphical adventure game for the +3e environment from scratch so that I can learn drawing routines, perhaps starting in C and then to ASM - the latter is the true goal, perhaps only using C as a wrapper for the ASM in the long run. The game would based on the 8bit/16bit IDE hard disk device so graphical / audio size is not an issue and would be loaded when required.
So any hints / tips / books recommended would be an absolute treasure - thanks for reading
Comments
http://bulba.untergrund.net/vortex_e.htm
Eventually the plan would be to have data-bins loaded into RAM when needed - I have managed to load data files to memory from a +3e environment using C (z88DK) =) just need to learn how to draw to the screen (properly) - currently I am reading this - https://chuntey.wordpress.com/category/z80-assembly/page/3/
Might have a crack at getting this to work in a +3 environment =)
I've been online constantly, it's you who's been AWOL! :p
With loading from disk, you have to tell the DOS at what memory address to load the data. So the way to go about it is to just load the data to some free address and decompress to the screen (if using something like zx7), memcpy to the screen (you could have loaded it directly) or copy in a loop if the data is a rectangle on screen (see the zx screen address functions that manipulate screen addresses to move up/down pixel lines and so on).
This free address block can be reserved inside the binary or it could be reserved outside the binary and outside the compiler's awareness.
Doing the latter (outside the compiler's awareness), you could reserve memory space (in your mind) just after the display file to load data from disk. This way you recoup memory lost to basic when the program was loaded with a small basic loader. You would then pass on the fixed memory address to the load subroutine as an integer like "23296".
Doing the former, you can reserve memory in a character array like "unsigned char buffer[1024];" and load the disk data to address "buffer". You can also place the buffer at a specific address if you reserve space for it in a section but this is more applicable for programs that run from more than 64k (like if you were to compile code that uses the full 128k spectrum's memory). I'll show how to do that anyway from asm:
"myasm.asm"
In your C:
When you compile just add all your source files to the compile line (.c, .asm, .o).
If you need to allocate temporary buffer space in an organized way, you can use malloc but perhaps more appropriate in many circumstances is to use an obstack as provided by the new c library. An obstack is given some block of memory and it allocates objects one after the other. There are no holes and things are very fast but you can't randomly free objects as in malloc,
Andy started some topics on drawing lines and ellipses in the z88dk forums: http://www.z88dk.org/forum/viewforum.php?id=2
This code is meant to compile with the new c lib but it will run with minor mod on the classic c lib. The code can certainly be improved but at least you can see how to go about things. I don't think Andy actually posted complete test programs but if you really want to see it, I can maybe provide complete programs.
As for sprites and stuff, z88dk does contain a number of engines. The classic and new c libs both contain sp1 which has been used for around 30 games, mainly written by nathan and timmy. The new c lib comes with Einar's bifrost and nirvana engines built in. If you look in z88dk/libsrc/_DEVELOPMENT/EXAMPLES/zx you will find example programs that use all of these. The classic c lib also contains a black and white grahpucs library that will draw lines, etc. And of course if you want to do your own thing, that's good too.
I think it was already mentioned :- Vortex tracker for the PC for AY music. It will generate an asm routine that needs to be run on each interrupt which is easy enough to incorporate into z88dk. For the beeper there is Beepola. The tritone music engine is built into the new c lib as is beepfx (see examples in that example dir).
If the program will fit into a 128k spectrum I would load all the data into banks needed in basic before the C program starts. That way anyone can modify the basic loader to run on their disk system.
However, if you have something really big that will not fit into 128k, then you should do what you are doing.
As guesser mentioned, disk i/o is only available with the classic c library and is unavailable from the new c library as of now. The new c library has a number of advantages over the classic c lib right now but that will go away with time. Among them, the new c lib completely implements the section model so it's easy to place stuff / compile code into multiple memory banks and it fully supports sdcc as compiler (z88dk's version produces much better code btw). The classic c lib has been moving to the section model and this is nearly complete (most things will work) and most library functions are supported for sdcc.
Write games in C using Z88DK and SP1
Hello Zetr0 you wonderful person, it's good to see you again!
Feel free to help yourself to the Sinclair ZX Spectrum +3 Manual.pdf
Its good to have some time to see you guys again! let alone work on a project or two for the spectrum =D
I've got the testing code, right now it looks like crud (unorganized and quite messy). I can clean it up and post it sometime soon. I'm still playing around with trying to create an integer only bezier curve (which is giving me trouble).
All of the routines are graphic primitives.
I've got plot, unplot, line, circle, triangle, square, rectangle, ellipse, arc, parabola, and Bezier (Quadratic and Cubic). The last 2 are floating point. I was going to place all of it on Github for everyone to modify/optimize.
Andy Dansby
A mostly unoptimized work in progress. Anyone is welcome to use them for whatever they want. Even as an example of what not to do. If you like to add/modify/optimize, feel free, just share.
Alvin helped out with plot and unplot, of which none of the other routines would have been possible.
Andy Dansby
Interesting, I shall keep an eye on that.. I'm looking for some quick line routines, so this should be pretty handy, thanks, :)
If you want to turn up the optimization:
You may also want to structure the graphics code as a library so others' code can link against it, the advantage being programs will only grab what routines they actually use from a library.
Write games in C using Z88DK and SP1
Whoops, I placed the code there, and simply forgot to commit, so none of the files were uploaded. Should be ok now.
As for the optimizer, I do use it on occasion if I remember. Sometimes it's difficult to remember all the options. Perhaps a C# form having all the various options and then output a string to paste inside a dos window may be in order. It might help goofballs like me to remember the options.
When I am experimenting, I usually don't use the optimization only because it takes longer to compile, so I just use the basics for compiling and if it eventually works, I turn it on (if I remember).
As for making it into a library, only grabbing the routines is an excellent idea. I just need to figure out how to do that, not that I know what I'm doing other than experimentation (and having a bit of coding fun). In real life, I'm not a programmer, I'm a phone technician.
Andy Dansby
The basic unit of extraction from a library is the file so what you'd want to do is separate your routines into one function per file and your variables to one group per file (a group being if any variable is referenced, all of them will be needed). You can list all the source files in the library in a .lst file. So there would be a ZXPlot.c, ZXUnplot.c, etc. Let's call it zxgraph.lst
After that's done a compile equivalent to the original would be:
zcc +zx -vn -lm -clib=sdcc_iy -startup=1 main.c @zxgraph.lst -o main -create-app
Instead of zxgraph.c we're listing a whole bunch of files in "zxgraph.lst". This is equivalent to the original compile because all the source code will be in the output binary.
Adding -x makes a library:
zcc +zx -vn -lm -x -clib=sdcc_iy -startup=1 @zxgraph.lst -o zxgraph -create-app
Most of those options are ignored because you're not building a binary (it's important to get main.c out of there because you don't want it in the library). A more succinct make-lib line would be:
zcc +zx -vn -x -clib=sdcc_iy @zxgraph.lst -o zxgraph
but a regular compile line is accepted just to make things easy.
The output will be "zxgraph.lib". You can examine what's in the library with "z80nm zxgraph.lib"
Then a compile like this:
zcc +zx -vn -lm -lzxgraph -clib=sdcc_iy -startup=1 main.c -o main -create-app
will only pull out the graphics functions that main.c actually references.
There are a few details like how to make the library compatible with both sdcc and sccz80 but they're not too bad if you begin with the idea of making a compatible library.
About the options, you can see a short listing here:
http://www.z88dk.org/wiki/doku.php?id=libnew:target_embedded#selected_command_line_options
The rest of the page also applies to the zx target as all targets are based on that one but the zx target will have different defaults and more things in it.
There is a short write-up specifically about optimization here:
http://www.z88dk.org/wiki/doku.php?id=temp:front#optimization_level
***Unfortunately the z88dk buildbot is broken and is not packaging win32 or osx binaries with recent downloads. If you grab a recent win32 build you can use my win32 binaries by placing them in z88dk/bin
Write games in C using Z88DK and SP1