But it's still true to say that on the 48 you can't update an attribute until it's been drawn.
Not sure what you mean. You do have to time it very carefully. Once you've set an attribute, it has to get rendered twice (over two rows) before you change it again. Just changing things in the border time isn't good enough - you have to work around the raster in some of the screen rendering time, and there's some wasted time too. I'm really not completely sure what happens in contention and what doesn't.
Remind me, are all 28 attributes independently programmable?
They are. In the screen you saw the buffer was filled by a macro so they were repetitive patterns. Similarly the pixels were just a few scenery blocks repeated and inverted in the top half of the screen. But the bytes in the colour buffer are all independent.
I think you also saw the 24-character wide one with some platform blocks scrolling up and down - those are independent, and the colours can obviously be scrolled by changing the buffer pointer.
You don't really need to have the tiles in a separate block, alternatively you can compile the tiles embedded into your code at an arbitrary location, then use BIFROSTresetTileImages(..) specifying the label to this address. But afterwards you will still need to load the "BIFROST*" code block after your compiled program, then re-save both together as above.
Now load this program into an emulator (it will wait at line 40 waiting for the last block), and save a snapshot at this point.
Whenever you want to test your compiled program, simply load the snapshot first, then insert the TAP file generated by the compiler. It will load and run your test program automatically, with everything else already set properly on memory.
Technically that's easy. In BIFROST* source code, just need to change REPT 18, ROWREPT to the number of lines you want, then readjust address references accordingly.
Good to know that's for aesthetic and logistics reasons, rather than technical. I realise it would eat almost all the CPU. But for art's sake, I could see people doing it - just so they could say they got the art onto a 48K zx spectrum. Even if it's working like crazy under the surface.
For art's sake, you could even have Rotatrix animations both in the upper and lower borders, and all 24 rows of BIFROST* on screen.
This would still give you something like 6K T-states left before the upper border (enough time to animate tiles in BIFROST* at "slow animation" speed) and 6K T-states after the lower border per frame (enough time to implement a simple game).
It's certainly feasible, but probably not worth the effort :)
I decided there won't be a version 1.3. Instead, I will expand the current 1.2 package so it will become a "dual release", including 2 variations:
1.2 Low: A smaller, faster version that directly draws tiles at "low-res" coordinates (i.e. the current release). This will be the best choice for creating games that only print tiles at the regular PRINT AT positions (like in Bozxle).
1.2 High: A more complex version that directly draws tiles at "hi-res" coordinates (i.e. what I previously planned for 1.3). This will be useful for games that need to print tiles at arbitrary PLOT-like positions (similar to Buzzsaw for instance).
The main reason is that it's better if both variants share the same documentation, since the majority of the tech information is identical for both. I don't want people to spend time reading 2 different documents when most of the content is identical, and it would be weird if 2 different version numbers shared the same documentation.
Moreover, too many people don't even pay attention to documentation. If I posted separate versions 1.2 and 1.3 intended for different purposes, most people would simply ignore 1.2 and just download 1.3. Providing a dual 1.2 release instead will avoid this issue.
I'm already working on this second variant, that I hope to release later this week!
Einar - will this mean, for example, that one could have a small number of sprites that are full colour, on a standard background; recovering T states (at reti) pretty much as soon as it's done the bottom one?
Ooh.
If so, I am so going back to Berksman and seeing if I can shoehorn it into full colour ghosts and pacman without clashing with the maze lines.
Einar - will this mean, for example, that one could have a small number of sprites that are full colour, on a standard background; recovering T states (at reti) pretty much as soon as it's done the bottom one?
No, it will still have the same multicolor area.
The practical difference is that you will be able to move each tile an arbitrary number of pixels up/down and an arbitrary number of char columns left/right.
The standard functionality works the same as previous versions, i.e. you can simply put tile numbers into the tile map and BIFROST* will automatically draw/animate everything for you. This is still the easiest way to use BIFROST*.
However, if someone is planning to develop games that will access the new internal routines to directly draw tiles instantly on screen, I strongly recommend reading the new sections "ADVANCED PROGRAMMING" and "TILE COORDINATES" from the latest documentation.
This is probably the final version of BIFROST*. I may still consider adding a few more useful routines to help developers, but there will be no major changes anymore.
I believe I have now achieved my intent to provide a multicolor tool that is as generic, flexible, small and efficient as possible. This final implementation is supposed to fit all kinds of games, interfering as little as possible with everything else, so programmers can use it freely to do whatever they want. This is exactly the goal I originally posted the day I released the first version. Moreover, the current documentation is very detailed and complete, I can't imagine anything else that would be relevant enough to add there.
As usual, further comments, suggestions and criticisms are welcome!
Brillant! I am silly to spent all my time with programming instead of listening the very fantastic things that happen around that multicolor theme! Be sure from now on I will follow your progresses on that great work more often!
Fantastic!!!! :-):-):-)
There are no problems, only solutions (K. Flynn)
Visit my ZX-Modules homepage with lot of free programs!
Or visit my music-related website if you're interested in synthesizer music or computer animations and movies I've created
Brillant! I am silly to spent all my time with programming instead of listening the very fantastic things that happen around that multicolor theme! Be sure from now on I will follow your progresses on that great work more often!
Fantastic!!!! :-):-):-)
There's nothing to stop you doing all 192 rows of the screen, except the processor time and memory that gets swallowed up. In one frame you've effectively got 312 rows, of which you lose the first 56 waiting for the top border. So then another 100 rows of multicolour means you've already lost 50% of your processing power for running the game .
Why waste? You can play the music of that time, I do not know about the beeper. But there is a AY player which takes a fixed number of tacts.
You can think of many things.
Why waste? You can play the music of that time, I do not know about the beeper. But there is a AY player which takes a fixed number of tacts.
Agreed.
Fixed time players can be invoked during the upper border, as explained in the BIFROST* documentation. And even if a music player (beeper or AY) takes a variable time, it will work if invoked right after the multicolor render, as also explained in the documentation.
AFAIK Pentagon doesn't have memory contention so I doubt the same render would work on it. And if it requires a different render, then a new config won't be enough, it will require changing everything.
Anyway I will take a look at this. Do you know where I can find detailed technical reference about Pentagon timings?
To be honest, I do not really present how great the game can be done at 24kb Spectrum ...
It seems you are not familiar with Bozxle and Buzzsaw!
And why did you mention a "24Kb Spectrum"? A standard 48K Spectrum has about 41K RAM available (excluding the 7K screen area). Bozxle only uses about 32K including ZXodus engine (which is about the same size as the largest version of BIFROST*). Buzzsaw uses all the available RAM but AFAIK this includes many lookup tables, thus the same game using BIFROST* would be probably smaller. In both cases, 41K RAM was more than enough!
After you finish drawing a multicolor tile, press SPACE to obtain the equivalent list of POKEs. It will be also updated soon so pressing ENTER will produce the sequence of numeric values directly.
Comments
They are. In the screen you saw the buffer was filled by a macro so they were repetitive patterns. Similarly the pixels were just a few scenery blocks repeated and inverted in the top half of the screen. But the bytes in the colour buffer are all independent.
I think you also saw the 24-character wide one with some platform blocks scrolling up and down - those are independent, and the colours can obviously be scrolled by changing the buffer pointer.
- IONIAN-GAMES.com -
What exactly do you want?
If you want to re-save everything as a single block, that's quite easy:
You don't really need to have the tiles in a separate block, alternatively you can compile the tiles embedded into your code at an arbitrary location, then use BIFROSTresetTileImages(..) specifying the label to this address. But afterwards you will still need to load the "BIFROST*" code block after your compiled program, then re-save both together as above.
But I realise I should create my own demo to start experimenting.
Ah! I see.
When I'm developing my own programs for BIFROST*, I keep a separate "LOADER.TZX" file with the following blocks:
- Program: "LOADER"
- Bytes: "TILES"
- Bytes: "BIFROST*"
The loader is the same as the original, but in a different order: Now load this program into an emulator (it will wait at line 40 waiting for the last block), and save a snapshot at this point.Whenever you want to test your compiled program, simply load the snapshot first, then insert the TAP file generated by the compiler. It will load and run your test program automatically, with everything else already set properly on memory.
Good to know that's for aesthetic and logistics reasons, rather than technical. I realise it would eat almost all the CPU. But for art's sake, I could see people doing it - just so they could say they got the art onto a 48K zx spectrum. Even if it's working like crazy under the surface.
Demos too, possibly.
I know. Use a SAM :) It's not the same ;)
For art's sake, you could even have Rotatrix animations both in the upper and lower borders, and all 24 rows of BIFROST* on screen.
This would still give you something like 6K T-states left before the upper border (enough time to animate tiles in BIFROST* at "slow animation" speed) and 6K T-states after the lower border per frame (enough time to implement a simple game).
It's certainly feasible, but probably not worth the effort :)
https://dl.dropbox.com/u/12332019/BiFrostZXODUS%20and%20Graphics.zip
It's a basic tile designer - doesn't do pretty bright and flash stuff (though it calculates the bytes for you).
In an excel spreadsheet :)
Thank you! :)
I decided there won't be a version 1.3. Instead, I will expand the current 1.2 package so it will become a "dual release", including 2 variations:
- 1.2 Low: A smaller, faster version that directly draws tiles at "low-res" coordinates (i.e. the current release). This will be the best choice for creating games that only print tiles at the regular PRINT AT positions (like in Bozxle).
- 1.2 High: A more complex version that directly draws tiles at "hi-res" coordinates (i.e. what I previously planned for 1.3). This will be useful for games that need to print tiles at arbitrary PLOT-like positions (similar to Buzzsaw for instance).
The main reason is that it's better if both variants share the same documentation, since the majority of the tech information is identical for both. I don't want people to spend time reading 2 different documents when most of the content is identical, and it would be weird if 2 different version numbers shared the same documentation.Moreover, too many people don't even pay attention to documentation. If I posted separate versions 1.2 and 1.3 intended for different purposes, most people would simply ignore 1.2 and just download 1.3. Providing a dual 1.2 release instead will avoid this issue.
I'm already working on this second variant, that I hope to release later this week!
Ooh.
If so, I am so going back to Berksman and seeing if I can shoehorn it into full colour ghosts and pacman without clashing with the maze lines.
No, it will still have the same multicolor area.
The practical difference is that you will be able to move each tile an arbitrary number of pixels up/down and an arbitrary number of char columns left/right.
http://www.worldofspectrum.org/infoseekid.cgi?id=0027405
The standard functionality works the same as previous versions, i.e. you can simply put tile numbers into the tile map and BIFROST* will automatically draw/animate everything for you. This is still the easiest way to use BIFROST*.
However, if someone is planning to develop games that will access the new internal routines to directly draw tiles instantly on screen, I strongly recommend reading the new sections "ADVANCED PROGRAMMING" and "TILE COORDINATES" from the latest documentation.
please check out my question at:
http://www.boriel.com/forum/post3494.html#p3494
Answered!
http://www.worldofspectrum.org/infoseekid.cgi?id=0027405
This is probably the final version of BIFROST*. I may still consider adding a few more useful routines to help developers, but there will be no major changes anymore.
I believe I have now achieved my intent to provide a multicolor tool that is as generic, flexible, small and efficient as possible. This final implementation is supposed to fit all kinds of games, interfering as little as possible with everything else, so programmers can use it freely to do whatever they want. This is exactly the goal I originally posted the day I released the first version. Moreover, the current documentation is very detailed and complete, I can't imagine anything else that would be relevant enough to add there.
As usual, further comments, suggestions and criticisms are welcome!
Fantastic!!!! :-):-):-)
There are no problems, only solutions (K. Flynn)
Visit my ZX-Modules homepage with lot of free programs!
Or visit my music-related website if you're interested in synthesizer music or computer animations and movies I've created
Thank you! :)
By the way this resolution 144х144 Gameboy classic ...
That theoretically allows you to convert some of the static-logic game.
Why waste? You can play the music of that time, I do not know about the beeper. But there is a AY player which takes a fixed number of tacts.
You can think of many things.
Look at the demoscene it uses each tact!
Good point!
And perhaps some of the simpler "dynamic" games also, using the techniques I'm going to demonstrate in the "advanced programming" demos...
Agreed.
Fixed time players can be invoked during the upper border, as explained in the BIFROST* documentation. And even if a music player (beeper or AY) takes a variable time, it will work if invoked right after the multicolor render, as also explained in the documentation.
Pentagon forever!
need config in compiler.
No matter if all the possible games will be in the top left corner.
Maybe I want to draw a nice menu/border around the screen?
To be honest, I do not really present how great the game can be done at 24kb Spectrum ...
AFAIK Pentagon doesn't have memory contention so I doubt the same render would work on it. And if it requires a different render, then a new config won't be enough, it will require changing everything.
Anyway I will take a look at this. Do you know where I can find detailed technical reference about Pentagon timings?
I also suspect different screen coordinates will require a different render. This is not as easy as you think.
It seems you are not familiar with Bozxle and Buzzsaw!
And why did you mention a "24Kb Spectrum"? A standard 48K Spectrum has about 41K RAM available (excluding the 7K screen area). Bozxle only uses about 32K including ZXodus engine (which is about the same size as the largest version of BIFROST*). Buzzsaw uses all the available RAM but AFAIK this includes many lookup tables, thus the same game using BIFROST* would be probably smaller. In both cases, 41K RAM was more than enough!
http://slenkar.herobo.com/brofist/brofist.html
After you finish drawing a multicolor tile, press SPACE to obtain the equivalent list of POKEs. It will be also updated soon so pressing ENTER will produce the sequence of numeric values directly.