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!
simple as that. graphics is 2 times more storage space.
Of course, if this is a pathetic socoban or tetris there are so few charts that even with every color on the point would be enough memory.
simple as that. graphics is 2 times more storage space.
However multicolor games must be designed for a reduced playing area since the multicolor area is roughly half the total screen size, thus in practice you should only need half the number of graphics.
It seems you are desperately trying to convince everyone that Pentagon is the only worthwhile hardware for games, thus BIFROST* (among others) must support the Pentagon considering it's far superior to the Spectrum. However that's irrelevant. If technical superiority was really the point, I would discard both Spectrum and Pentagon, and create engines exclusively for Playstation 3 instead.
As I mentioned before, I already agreed trying to port BIFROST* to Pentagon (if I can find the proper technical information about Pentagon timings), as long as it doesn't require reimplementing everything. But let's not turn this discussion into a Pentagon x Spectrum religious war.
But let's not turn this discussion into a Pentagon x Spectrum religious war.
Quite, since the Timex has been doing hardware multicolour since 1983. :) The problem with the Pentagon is that it's got no contention which means that unlike ZXodus, which uses rough guesses to sort out the timing, you have to be t-state precise. Frankly I don't think it's worth the effort to support the Pentagon for this kind of stuff given that limitation and the fact that a fair number of them support the Timex 8x1 attribute mode in hardware.
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?
Total in line : 32 + 36 + 128 + 28 = 224 tacts
Total in frame: 16 lns + 64 lns + 192 lns + 48 lns = 320 lines
from begin of INT: 3584t + 14336t + 43008t + 10752t = 71680tacts
80 lines = 17920 tacts
Signal INT forms wrong, in this computer time from begin of INT till end of frame is 320 lines = 71680 tacts. Therefore, after INT comes, it is useless to output anything on screen in first 16 lines = 3584 tacts, because in this time ray is moving up ( backtracing ).
It seems you are desperately trying to convince everyone that Pentagon is the only worthwhile hardware for games, thus BIFROST* (among others) must support the Pentagon considering it's far superior to the Spectrum. However that's irrelevant. If technical superiority was really the point, I would discard both Spectrum and Pentagon, and create engines exclusively for Playstation 3 instead.
In any case. In the end, the Pentagon is 128k.
Talking about that today from the Real Spectrum is the most popular Original 48k, 2+ and Pentagon (old lot of new ones).
I think that the game throwing technical challenge is meant to play on real hardware, not the emulator.
So what I'm saying, it's an opportunity to play on a real Spectrum to a lot of people count.
Many well-known to me Multicolor graphical editors allow you to adjust the timing right while drawing ...
Quite, since the Timex has been doing hardware multicolour since 1983. :) The problem with the Pentagon is that it's got no contention which means that unlike ZXodus, which uses rough guesses to sort out the timing, you have to be t-state precise. Frankly I don't think it's worth the effort to support the Pentagon for this kind of stuff given that limitation and the fact that a fair number of them support the Timex 8x1 attribute mode in hardware.
I'm not talking about that we could make games for Pentaton. I'm talking about what would be the game can be played on a larger number of different but real Spectrum. +2, +3, Scorpion and others.
I'm not talking about that we could make games for Pentaton. I'm talking about what would be the game can be played on a larger number of different but real Spectrum. +2, +3, Scorpion and others.
I'm just saying it would be easier to just use the hardware mode if a Pentagon is detected, rather than do all that tedious t-state counting.
Aowen, Aowen... Standard Pentagon (the one emulated by Spectaculator, Spin, SpecEmu, EmuZWin and whatever I know) doesn't have any extra hardware modes. It's Spectrum 128 with disk system. Really :)
Aowen, Aowen... Standard Pentagon (the one emulated by Spectaculator, Spin, SpecEmu, EmuZWin and whatever I know) doesn't have any extra hardware modes. It's Spectrum 128 with disk system. Really :)
There is no standard Pentagon. FUSE emulates three different models, at least one of which has 16C mode. I know RealSpectrum emulates the Pentagon 8x1 attribute mode (same as Timex mode, but activated on a different port). I'm surprised EmuZWin doesn't emulate it as it's been around almost as long as the original Pentagon design.
Total in line : 32 + 36 + 128 + 28 = 224 tacts
Total in frame: 16 lns + 64 lns + 192 lns + 48 lns = 320 lines
from begin of INT: 3584t + 14336t + 43008t + 10752t = 71680tacts
80 lines = 17920 tacts
Signal INT forms wrong, in this computer time from begin of INT till end of frame is 320 lines = 71680 tacts. Therefore, after INT comes, it is useless to output anything on screen in first 16 lines = 3584 tacts, because in this time ray is moving up ( backtracing ).
Without contention, the existing render will process each line in 207 T-states, thus 17 T-states too fast. Unfortunately there's no way to adjust the same render to make it 17 T-states longer within the same number of bytes. Also 17 T-states is not enough to jump somewhere else and then return.
It means I would have to rewrite the render loop specifically for the Pentagon, for instance adding 2 more bytes per iteration (total of 144x2=288 bytes) to waste another 17 T-states. Consequently all attribute addresses would be changed, thus it won't be possible to have the same version of BIFROST* working on both Spectrum and Pentagon. It also means reallocating all existing routines, since there would be not enough space for 288 extra bytes even if I sacrificed the jump vector table.
I suspect the only viable option would be source code compatibility: I can make the necessary adjusts in the BIFROST* source code and recompile it at a different address, but also provide a new library interface with equivalent routines, so game authors will be able to recompile their source code also and thus generate a separate version specifically for Pentagon.
If someone has a better suggestion, please let me know.
Frankly I don't think it's worth the effort to support the Pentagon for this kind of stuff given that limitation and the fact that a fair number of them support the Timex 8x1 attribute mode in hardware.
Actually... Another alternative would be reimplementing exactly the same BIFROST* library interface, but to directly use Timex 8x1 mode instead of BIFROST* itself. This way, games developed for BIFROST* could be recompiled to automatically work on both Timex machines and some Pentagon models.
Actually... Another alternative would be reimplementing exactly the same BIFROST* library interface, but to directly use Timex 8x1 mode instead of BIFROST* itself. This way, games developed for BIFROST* could be recompiled to automatically work on both Timex machines and some Pentagon models.
That's sort of what I meant. It's just my brain is addled from slogging away at this dissertation project.
Draw the tiles in an Excel spreadsheet created by Gedlion that calculates the equivalent values for you (available here)
Draw the tiles in the online editor created by slenkar that also calculates the equivalent values for you (available here).
Soon we should have even more tools:
An editor that p13z is developing in SpecBAS (screenshot here).
A future version of the BorIDE editor created by LCD will provide built-in support for BIFROST* (download here)
A future version of ZX-Paintbrush will allow selecting a section of a Timex screen and exporting it as multicolor tile directly.
If there's anything else I forgot to mention, please let me know!
Hello. When Zxodus was first released I created this simple converter so you can draw your graphics in your favourite editor and save them as png files, then convert them to the suitable format. Would it work with Bifrost*? (sorry, I haven't read the docs yet so I don't know if stuff is stored using the same format)
When Zxodus was first released I created this simple converter so you can draw your graphics in your favourite editor and save them as png files, then convert them to the suitable format. Would it work with Bifrost*? (sorry, I haven't read the docs yet so I don't know if stuff is stored using the same format)
Yes. Both ZXodus and Bifrost* use the ColorTILE format.
Hello. When Zxodus was first released I created this simple converter so you can draw your graphics in your favourite editor and save them as png files, then convert them to the suitable format. Would it work with Bifrost*? (sorry, I haven't read the docs yet so I don't know if stuff is stored using the same format)
I just need char ( 8x8 ) based movement in my game. Can I use the L variant, or do I need the H one? I seem to understand that the L variant can print at char coordinates, but this proggie doesn't seem to work:
' initialization stuff trimmed... blah blah bla.
While Inkey$ = ""
Asm
Halt
Halt
Halt
Halt
End Asm
BIFROSTfillTileAttrL (y, x, 0)
BIFROSTdrawTileL (y, x, 9)
x = x + mx
y = y + my
If x = 1 Or x = 17 Then mx = -mx: End If
If y = 1 Or y = 17 Then my = -my: End If
Wend
mx and my are 1, or -1. So it moves in char increments. But weird stuff appears on screen (random garbage here and there) besides the tile not printing correctly.
And obviously load the H interface library and code blocks instead.
Later, if you need better performance than L for a char-based game, let me know and I will prepare a custom "hybrid" variant (similar to the L variant but that can print at odd columns). This will make the L variant slightly slower, but still faster than H. If support for odd columns is all you need, this should be a good option.
That's nice, I'll try the H version. I think it will be fast enough, don't worry :) Anyways, a mid version for char based games would be a nice idea to consider for the future.
@Einar: It just occured to me that ColorPRINT-48 could easily be updated to allow multi-colour printing in Bifrost*. The source code is online so maybe you'd like to consider adding it to the engine. That would allow per character printing with 256 multi-colour UDGs from BASIC or machine code. Might give programmers some more options, and would make doing multi-colour text trivial.
Anyways, a mid version for char based games would be a nice idea to consider for the future.
Right now, variant L is optimized for size and performance, and variant H for maximum flexibility. As a general rule, I think it would be better to implement other intermediate versions under demand, when someone actually needs it. This way, I can implement it according to the specific requirements for a game.
For instance, variant H allows drawing/erasing tiles on the edges (such that half the tile will be hidden outside the multicolor area), variant L doesn't. Should this intermediate char-based version allow it or not? The implementation (especially timing) will be fairly different depending on this choice. The more features I add to an intermediate version, the closer it will get to variant H in terms of size and performance...
Another example is sprite tiles support. If someone is implementing a game that won't use any animated tiles, but needs better performance, I could disable the tile mapping completely and use the upper border time for drawing sprite tiles only. However this kind of implementation also depends on the specific requirements. Your choices would be:
Automatically drawing up to 9 sprite tiles at any char row, odd char column only (just like current variant "L");
Automatically drawing up to 7 sprite tiles at any char row, any char column (an intermediate char-based version without tiles at the edges);
Automatically drawing up to 6 sprite tiles at any pixel row, odd char columns only (this is how Buzzsaw works);
Automatically drawing up to 5 sprite tiles at any pixel row, any char column (just like current variant "H").
I'm available to implement custom versions of BIFROST* for anyone that really needs it. Developers can start implementing their games using one of the existing variants and, when the project is mature enough so they know all specific requirements they need for BIFROST*, I will implement a custom version. In the meantime, developers are welcome to contact me directly for advice, support or whatever they need, my contact email is available in the forum!
@Einar: It just occured to me that ColorPRINT-48 could easily be updated to allow multi-colour printing in Bifrost*. The source code is online so maybe you'd like to consider adding it to the engine. That would allow per character printing with 256 multi-colour UDGs from BASIC or machine code. Might give programmers some more options, and would make doing multi-colour text trivial.
I was considering to provide "plugins", i.e additional (more specific) routines that developers may choose to add or not according to their needs. Support for printing individual multicolor chars would be one of them.
This idea would give more options for end-users, while at the same time keeping BIFROST*'s core functionality as minimal, flexible and generic as possible, according to the design principle behind BIFROST* that I previously mentioned here. There's a quote I really like about design that says "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." (Antoine de Saint-Exupery).
However your suggestion makes a lot of sense. Perhaps it would be better to add BIFROST* support into existing tools like ColorPRINT-48, instead of implementing new plugins. Let me take a look at the source code first and I will get back to you on this. Thank you!
Automatically drawing up to 7 sprite tiles at any char row, any char column (an intermediate char-based version without tiles at the edges);
That one would fit my needs, I mean, I was trying to create a game in the fashion of my old BASIC games, which are nice platformers with character based movement. The 18x18 chars window would be great to design nice rooms with simple perils for the player and with 8x1 attributes this could look indeed really nice. Animated times would make this look better, besides.
I just need that my 16x16 tiles can be positioned at any character grid location, and that's all. Animated tiles would be a plus.
However your suggestion makes a lot of sense. Perhaps it would be better to add BIFROST* support into existing tools like ColorPRINT-48, instead of implementing new plugins. Let me take a look at the source code first and I will get back to you on this. Thank you!
OK, I checked ColorPRINT-48 source code.
For Assembly and compiled programs using BIFROST*, I think it's easier to just provide a 8x8 version of the current "draw_tile" routine, that can be accessed directly. This would be somewhat smaller and faster.
However, this is not an option for Sinclair BASIC programmers. In this case, adding BIFROST* support in ColorPRINT-48 would be the best option. Even better, I will make it automatically distinguish between BIFROST* 1.2 and ZXodus I, so the same version will support both.
Thus I decided to work on both options above. Thanks again!
I just need that my 16x16 tiles can be positioned at any character grid location, and that's all. Animated tiles would be a plus.
OK, I will implement a new char-based BIFROST* variant for you, to be called variant "C". Let me just confirm its requirements first, to be sure this new variant will match exactly what you need...
This is what you already have right now in BIFROST* variant H:
You can draw tiles at any location.
Erasing a tile takes 895T and drawing each tile takes up to 2730T. Since your program has about 20,000T available per frame, there's enough time to move at most 5 tiles on each frame (although it's usually less depending on how much time your program spends doing everything else).
The engine can automatically animate any number of tiles at fixed tile locations (i.e. at odd row and odd column). This won't waste any of the 20,000T your program has available per frame. However, if you want to animate tiles at other locations, you have to do it yourself "manually". In this case, if you animate tiles alternately, it means re-drawing 1 frame of 1 tile at a time, thus spending 1 tile draw invocation per frame to do it.
When using automatically animated tiles, you can choose if you want to animate all of them at 4 frames per second ("fast" mode) or 2 frames per second ("slow" mode). The official demo demonstrates both. If "slow" mode is good enough for you, then it's possible to use sprite tiles. These are 2 special tiles that the engine automatically draws (but does not erase) at any location every frame, always in front of everything else, without wasting any of the 20,000T your program has available per frame.
Thus I believe you already have everything you need in variant H. In practice, the new variant C will be a little smaller and faster than variant H, although not much different, as follows:
Variant C will be about 1.5K shorter than variant H.
Drawing tiles would be a little faster (probably around 2000T), thus your program would have time to draw and erase 6 tiles per frame instead of 5.
There will be 4 sprite tiles available in "slow" mode instead of 2.
However it won't be possible to draw tiles on the edges (i.e half the tile outside the multicolor area).
Automatically drawing up to 7 sprite tiles at any char row, any char column (an intermediate char-based version without tiles at the edges);
Automatically drawing up to 6 sprite tiles at any pixel row, odd char columns only (this is how Buzzsaw works);
Wrong way round - Buzzsaw+ redraws 7 sprites on any pixel row and any character column each frame, barring overlaps off the edge of the colour area. (And after the frame it can erase up to 3 of them). There are three moving sprites, 3 animated in the hopper, and the Goit at the side. But it has a massive table of addresses to speed up the drawing, then wastes loads of time on scanning the entire keyboard. :-?
You may want to copy the idea of erasing sprites after the colour routine, by just setting their attributes to black. It means they're there while the colours are rendered but gone by the next frame and can just be redrawn in the new position.
P.S. na_th_an, those are some nice tiles. I particularly like the colouring on the chain, and the ice block is great.
Comments
Soon we should have even more tools:
If there's anything else I forgot to mention, please let me know!
simple as that. graphics is 2 times more storage space.
Of course, if this is a pathetic socoban or tetris there are so few charts that even with every color on the point would be enough memory.
But we want real great games?
It seems you are desperately trying to convince everyone that Pentagon is the only worthwhile hardware for games, thus BIFROST* (among others) must support the Pentagon considering it's far superior to the Spectrum. However that's irrelevant. If technical superiority was really the point, I would discard both Spectrum and Pentagon, and create engines exclusively for Playstation 3 instead.
As I mentioned before, I already agreed trying to port BIFROST* to Pentagon (if I can find the proper technical information about Pentagon timings), as long as it doesn't require reimplementing everything. But let's not turn this discussion into a Pentagon x Spectrum religious war.
Quite, since the Timex has been doing hardware multicolour since 1983. :) The problem with the Pentagon is that it's got no contention which means that unlike ZXodus, which uses rough guesses to sort out the timing, you have to be t-state precise. Frankly I don't think it's worth the effort to support the Pentagon for this kind of stuff given that limitation and the fact that a fair number of them support the Timex 8x1 attribute mode in hardware.
Total in line : 32 + 36 + 128 + 28 = 224 tacts
Total in frame: 16 lns + 64 lns + 192 lns + 48 lns = 320 lines
from begin of INT: 3584t + 14336t + 43008t + 10752t = 71680tacts
80 lines = 17920 tacts
Signal INT forms wrong, in this computer time from begin of INT till end of frame is 320 lines = 71680 tacts. Therefore, after INT comes, it is useless to output anything on screen in first 16 lines = 3584 tacts, because in this time ray is moving up ( backtracing ).
http://www.worldofspectrum.org/rusfaq/#21
In any case. In the end, the Pentagon is 128k.
Talking about that today from the Real Spectrum is the most popular Original 48k, 2+ and Pentagon (old lot of new ones).
I think that the game throwing technical challenge is meant to play on real hardware, not the emulator.
So what I'm saying, it's an opportunity to play on a real Spectrum to a lot of people count.
Many well-known to me Multicolor graphical editors allow you to adjust the timing right while drawing ...
I'm not talking about that we could make games for Pentaton. I'm talking about what would be the game can be played on a larger number of different but real Spectrum. +2, +3, Scorpion and others.
I'm just saying it would be easier to just use the hardware mode if a Pentagon is detected, rather than do all that tedious t-state counting.
There is no standard Pentagon. FUSE emulates three different models, at least one of which has 16C mode. I know RealSpectrum emulates the Pentagon 8x1 attribute mode (same as Timex mode, but activated on a different port). I'm surprised EmuZWin doesn't emulate it as it's been around almost as long as the original Pentagon design.
Thanks for the info!
Without contention, the existing render will process each line in 207 T-states, thus 17 T-states too fast. Unfortunately there's no way to adjust the same render to make it 17 T-states longer within the same number of bytes. Also 17 T-states is not enough to jump somewhere else and then return.
It means I would have to rewrite the render loop specifically for the Pentagon, for instance adding 2 more bytes per iteration (total of 144x2=288 bytes) to waste another 17 T-states. Consequently all attribute addresses would be changed, thus it won't be possible to have the same version of BIFROST* working on both Spectrum and Pentagon. It also means reallocating all existing routines, since there would be not enough space for 288 extra bytes even if I sacrificed the jump vector table.
I suspect the only viable option would be source code compatibility: I can make the necessary adjusts in the BIFROST* source code and recompile it at a different address, but also provide a new library interface with equivalent routines, so game authors will be able to recompile their source code also and thus generate a separate version specifically for Pentagon.
If someone has a better suggestion, please let me know.
Actually... Another alternative would be reimplementing exactly the same BIFROST* library interface, but to directly use Timex 8x1 mode instead of BIFROST* itself. This way, games developed for BIFROST* could be recompiled to automatically work on both Timex machines and some Pentagon models.
That's sort of what I meant. It's just my brain is addled from slogging away at this dissertation project.
Hello. When Zxodus was first released I created this simple converter so you can draw your graphics in your favourite editor and save them as png files, then convert them to the suitable format. Would it work with Bifrost*? (sorry, I haven't read the docs yet so I don't know if stuff is stored using the same format)
http://worldofspectrum.org/forums/showpost.php?p=561632&postcount=15
Yes. Both ZXodus and Bifrost* use the ColorTILE format.
Sorry I forgot to mention your tool!
I just need char ( 8x8 ) based movement in my game. Can I use the L variant, or do I need the H one? I seem to understand that the L variant can print at char coordinates, but this proggie doesn't seem to work:
mx and my are 1, or -1. So it moves in char increments. But weird stuff appears on screen (random garbage here and there) besides the tile not printing correctly.
You need the H variant. The L variant only supports printing at odd columns (1,3,5..17).
Just for testing, you can easily edit your program to use H by replacing this: with this: And obviously load the H interface library and code blocks instead.
Later, if you need better performance than L for a char-based game, let me know and I will prepare a custom "hybrid" variant (similar to the L variant but that can print at odd columns). This will make the L variant slightly slower, but still faster than H. If support for odd columns is all you need, this should be a good option.
That's nice, I'll try the H version. I think it will be fast enough, don't worry :) Anyways, a mid version for char based games would be a nice idea to consider for the future.
Right now, variant L is optimized for size and performance, and variant H for maximum flexibility. As a general rule, I think it would be better to implement other intermediate versions under demand, when someone actually needs it. This way, I can implement it according to the specific requirements for a game.
For instance, variant H allows drawing/erasing tiles on the edges (such that half the tile will be hidden outside the multicolor area), variant L doesn't. Should this intermediate char-based version allow it or not? The implementation (especially timing) will be fairly different depending on this choice. The more features I add to an intermediate version, the closer it will get to variant H in terms of size and performance...
Another example is sprite tiles support. If someone is implementing a game that won't use any animated tiles, but needs better performance, I could disable the tile mapping completely and use the upper border time for drawing sprite tiles only. However this kind of implementation also depends on the specific requirements. Your choices would be:
- Automatically drawing up to 9 sprite tiles at any char row, odd char column only (just like current variant "L");
- Automatically drawing up to 7 sprite tiles at any char row, any char column (an intermediate char-based version without tiles at the edges);
- Automatically drawing up to 6 sprite tiles at any pixel row, odd char columns only (this is how Buzzsaw works);
- Automatically drawing up to 5 sprite tiles at any pixel row, any char column (just like current variant "H").
I'm available to implement custom versions of BIFROST* for anyone that really needs it. Developers can start implementing their games using one of the existing variants and, when the project is mature enough so they know all specific requirements they need for BIFROST*, I will implement a custom version. In the meantime, developers are welcome to contact me directly for advice, support or whatever they need, my contact email is available in the forum!I was considering to provide "plugins", i.e additional (more specific) routines that developers may choose to add or not according to their needs. Support for printing individual multicolor chars would be one of them.
This idea would give more options for end-users, while at the same time keeping BIFROST*'s core functionality as minimal, flexible and generic as possible, according to the design principle behind BIFROST* that I previously mentioned here. There's a quote I really like about design that says "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." (Antoine de Saint-Exupery).
However your suggestion makes a lot of sense. Perhaps it would be better to add BIFROST* support into existing tools like ColorPRINT-48, instead of implementing new plugins. Let me take a look at the source code first and I will get back to you on this. Thank you!
That one would fit my needs, I mean, I was trying to create a game in the fashion of my old BASIC games, which are nice platformers with character based movement. The 18x18 chars window would be great to design nice rooms with simple perils for the player and with 8x1 attributes this could look indeed really nice. Animated times would make this look better, besides.
I just need that my 16x16 tiles can be positioned at any character grid location, and that's all. Animated tiles would be a plus.
OK, I checked ColorPRINT-48 source code.
For Assembly and compiled programs using BIFROST*, I think it's easier to just provide a 8x8 version of the current "draw_tile" routine, that can be accessed directly. This would be somewhat smaller and faster.
However, this is not an option for Sinclair BASIC programmers. In this case, adding BIFROST* support in ColorPRINT-48 would be the best option. Even better, I will make it automatically distinguish between BIFROST* 1.2 and ZXodus I, so the same version will support both.
Thus I decided to work on both options above. Thanks again!
OK, I will implement a new char-based BIFROST* variant for you, to be called variant "C". Let me just confirm its requirements first, to be sure this new variant will match exactly what you need...
This is what you already have right now in BIFROST* variant H:
- You can draw tiles at any location.
- Erasing a tile takes 895T and drawing each tile takes up to 2730T. Since your program has about 20,000T available per frame, there's enough time to move at most 5 tiles on each frame (although it's usually less depending on how much time your program spends doing everything else).
- The engine can automatically animate any number of tiles at fixed tile locations (i.e. at odd row and odd column). This won't waste any of the 20,000T your program has available per frame. However, if you want to animate tiles at other locations, you have to do it yourself "manually". In this case, if you animate tiles alternately, it means re-drawing 1 frame of 1 tile at a time, thus spending 1 tile draw invocation per frame to do it.
- When using automatically animated tiles, you can choose if you want to animate all of them at 4 frames per second ("fast" mode) or 2 frames per second ("slow" mode). The official demo demonstrates both. If "slow" mode is good enough for you, then it's possible to use sprite tiles. These are 2 special tiles that the engine automatically draws (but does not erase) at any location every frame, always in front of everything else, without wasting any of the 20,000T your program has available per frame.
Thus I believe you already have everything you need in variant H. In practice, the new variant C will be a little smaller and faster than variant H, although not much different, as follows:Agreed?
You may want to copy the idea of erasing sprites after the colour routine, by just setting their attributes to black. It means they're there while the colours are rendered but gone by the next frame and can just be redrawn in the new position.
P.S. na_th_an, those are some nice tiles. I particularly like the colouring on the chain, and the ice block is great.
- IONIAN-GAMES.com -