Enterprise Forever
:UK => Programming => Topic started by: ssr86 on 2015.September.21. 21:11:20
-
Just a rant I guess. Maybe someone has some experirnce with these topis and could share...
Unfortunately I don't find the modes very useful for an ingame engine for a more graphic game...
The problem for using the character modes in games is the unfortunate lack of hardware sprites... This narrows the possible uses for the modes. That's because you have to share font matrices with sprite-building blocks. This way you limit the number of different objects/animation frames that can be used...
And you would need to constantly copy another animation frame's building-block to the font memory (but good only for the main character; when more enemies and every object in a different animation frame then you run out of characters... could not true for smaller sprites I guess).
There are games like Astro Marine Corps or Invasion of Zombie monsters for other z80 computers that "emulate" a character based mode. However this "emulation" takes down the limit of possible font sets per line etc. But this is not as fast and optimal as a real character mode could be.
-
did you read the hungarian topic "Karakteres grafikus módok"?
I have some demos with character modes (bit only the 2 color mode), but in that topic I try to make something in little used "4 colored character" modes
your questions: I think 256 character is enough to make fake sprites but you need to make very complex code
-
from the other topic, a little graphics in basic + the strange char mode :)
-
did you read the hungarian topic "Karakteres grafikus módok"?
I have some demos with character modes (bit only the 2 color mode), but in that topic I try to make something in little used "4 colored character" modes
Will take a look:)
your questions: I think 256 character is enough to make fake sprites but you need to make very complex code
Could you write some more about the needed code mechanism?
-
Look the Panic Man from geco. And Boulder Dash conversions from IstvanV (these are the non Spectrum versions).
-
And you can use more character map for a character game, for example 1st third of the screen uses 1 character map, 2nd third of the screen another character map, and 3rd third of the screen a third version of character map, in this case you have 3*256 (or 3*128, or 3*64) characters based on the definitions, even there is a crazy solution, every character row has it's own character set :D
-
The problems I see are:
- ep characters are only 1 byte in width (?...or so I think I remember reading) so only 2 pixels in pixel-16; you'd need at least two chars to get a standard 4x8 font - this somewhat halves the number of chars in a set
- you'd need to reserve some chars in every set for each character-sprite, so that you can copy the needed sprite blocks in them (so for example you use quarter/half a set for background tiles and the rest is reserved for sprite-tiles)
- managing the sprites and font sets would be hard and a lot of data moving invloved... or so I think
for smaller sprites maybe that'd not be all that bad but for more and bigger sprites...quite problematic I guess... Although I'm very curious how much better (if any) it would be than pixel modes speed- and memory-wise
did you read the hungarian topic "Karakteres grafikus módok"?
I have some demos with character modes (bit only the 2 color mode), but in that topic I try to make something in little used "4 colored character" modes
I have big problems understanding what the google translator is trying to tell me.:(
Most of the time I just skim through most of them and run all attached files...:oops:
Look the Panic Man from geco. And Boulder Dash conversions from IstvanV (these are the non Spectrum versions).
beautiful press fire/hiscore table screen
-
The problems I see are:
- ep characters are only 1 byte in width (?...or so I think I remember reading) so only 2 pixels in pixel-16; you'd need at least two chars to get a standard 4x8 font - this somewhat halves the number of chars in a set
- you'd need to reserve some chars in every set for each character-sprite, so that you can copy the needed sprite blocks in them (so for example you use quarter/half a set for background tiles and the rest is reserved for sprite-tiles)
- managing the sprites and font sets would be hard and a lot of data moving invloved... or so I think
1st point: there are 4 pixels in one character, because in character mode 4 colours/character available in 160x200 resolution, and if I remember well maximum 8 colours can be used in the same time in a character row in CHR64 mode.
2nd point: yes :)
3rd point: if the screen is splitted to 3 part, it can be managed easily.
beautiful press fire/hiscore table screen
The truth is that, the character set is from Sub hunter, and I used the bubbles which I made also into Sub Hunter based on C64 version.
-
1st point: there are 4 pixels in one character, because in character mode 4 colours/character available in 160x200 resolution, and if I remember well maximum 8 colours can be used in the same time in a character row in CHR64 mode.
"In the character modes, LD2 points to a character font and LD1 points to the character codes to be displayed. One character code is read, and the font byte for it fetched, in each slot, allowing up to 42 characters per line. VRES should always be clear for character modes. The three character modes vary only in the number of characters in the font, and therefore the amount of RAM required for the font. Ch128 will be used as an example in this description, the other two modes follow trivially."
oops:oops:
The note about vres is just so that you don't draw only the first line, right?
But it says that all three char modes differ only in the required memory for the matrices... Are there no other features?
-
The note about vres is just so that you don't draw only the first line, right?
But it says that all three char modes differ only in the required memory for the matrices... Are there no other features?
Yes, because in this mode the character map is read from the memory for each scan line it is the same, and the pointer is changing in the character set.
Yes,
in CH256 mode you can use color0,color1 pair from the palette
in CH128 mode you can use color0,color1, and color2,color3 pair from the palette
in CH64 mode you can use color0,color1, color2,color3, color4,color5, and color6,color7 pair from the palette
in 2 colour mode.
There is a feature also, in 2 colour graphics mode you can use more colours by using MSBALT, LSBALT bit of margin bytes, and if I remember well ALTIND0/1 has also effect, but may be i have wrong.
-
Watched "invasion of zombie monsters" for the msx.
https://www.youtube.com/watch?v=_tOdSysOyy4
(Ep could pull a perfect msx conversion with its character modes in 2color lpixel.
I wonder if the authors would kindly share the source code with the person who would want to do such conversion...)
The game has "small" sprites - they're max 3x3 chars (excluding the bosses). And the variety of the enemies per level is small too. So it'd be easier to "manage" the character sets I guess... But what about a game with sprites at least 2 times bigger (the main character) and say - also more variety in the enemy sprites (although already having them bigger would already make it more difficult I guess)...
Unfortunately (?) the character modes are the next best thing (?) for fast games (although jerky) when no hardware sprites are available... However the best is to have both;P... like the c64 scene shows.
-
wow that msx game is amazing!
and as I read, msx has z80 too. so we dont need the source codes
-
in CH256 mode you can use color0,color1 pair from the palette
in CH128 mode you can use color0,color1, and color2,color3 pair from the palette
in CH64 mode you can use color0,color1, color2,color3, color4,color5, and color6,color7 pair from the palette
in 2 colour mode.
It is actually possible to use ALTIND0/ALTIND1 in all video modes, including even PIXEL modes. Unlike LSBALT and MSBALT, these do not clear the bits they use, so it is possible to have 4 pairs of colors in 2-color CH256 mode:
- characters 0 to 63 will use colors 0 and 1
- characters 64 to 127 will use colors 4 and 5 (ALTIND0)
- characters 128 to 191 will use colors 2 and 3 (ALTIND1)
- characters 192 to 255 will use colors 6 and 7 (ALTIND0+ALTIND1)
-
including even PIXEL modes.
hm I must try this
-
My Scramble Demo on the Creativision with Scrolling use also a Char-Mode because the TMS9928 chip, same as in MSX I and Colecovision, has no hardware scrolling.
https://www.youtube.com/watch?v=lvdcr4mt8jU
In my Shamus game i use also a Char-Mode, also for the shot etc.
https://www.youtube.com/watch?v=1zuG2HPaL2k
Mobsie
-
Either I'm doing something wrong or the VRES doesn't work in char modes as in pixel modes... I can't get the char lines to repeat. For line_height = x I get x different lines...
Well... I must have completely misunderstood everything...:
"VRES should always be clear for character modes."
So I guess it's just how it should normally be... Then it seems you can't get the lines to repeat without doing a seperate modeline for each line of display... That makes the already big lpt even bigger...
Or am I missing something?
"The first 128 bytes of the font are the display bytes for the top scanline of each of the 128 characters. The next 128 bytes are the display bytes for the second scanline and so on. " (about ch128 from nick doc)
This is why I thought that 1char=1byte (two pixels in c16)... So I guess it's an error in the doc...
-
Either I'm doing something wrong or the VRES doesn't work in char modes as in pixel modes... I can't get the char lines to repeat. For line_height = x I get x different lines...
Well... I must have completely misunderstood everything...:
"VRES should always be clear for character modes."
I think this is because: according the specification, "if VRES is set then the next scanline of this modeline continues at the next byte in video RAM, if VRES is clear then the LD1 pointer is reloaded so the same data will be displayed on each scanline." This is written for PIXEL mode, but I think this sentence is true for every video modes (what VRES actually does with LD1 is the same in every modes) just in some cases it simply does not make any sense in a given video mode, because the nature of that mode (like in ch modes?)! So actually effect of VRES bit set/reset - I think, again! - works the very same way in every modes, just the "visible result" is different because different modes uses LD1/LD2 in different ways then to "show" pixels then on your screen ...
So VRES bit seems to set the behaviour of LD1 in the mentioned way. I guess it does something similar in character mode as well (or generally in every modes), just it does not make sense there to use "VRES is set" state. In ch mode, LD1 defines the character codes to be displayed (and LD2 points to the font data). Now that explains very well, why specification says, that "VRES should be clear" for character modes: one LPB describes one character line, the number of scanlines for the LPB defines the height of the used ch pixels (this is also a strength of Nick, that the height of a char is not defined at all just only by user, eg in Commodore 64 is strictly 8 pixels unless some very complex raster interrupt timed tricks are used or so, by burning significant amount of your CPU time just for this, by also exploiting some VIC-II "bugs" maybe). Since for every new scanlines of a given character involves the next line of font data of the character, LD2 can change and will at the same column of next line. However since line by line Nick should show the newer and newer line of the font data of the SAME CHARACTER CODE, it means, LD1 should be the same during this process, that is, LD1 should be re-loaded at every scanline, that is, VRES should be clear for this ... Of course you can actually set VRES in ch mode, just the result will be ... well ... interesting :) You can guess what it does with VRES set, if you know how exactly LD1 and LD2 is used in ch modes ...
Either I'm doing something wrong or the VRES doesn't work in char modes as in pixel modes... I can't get the char lines to repeat. For line_height = x I get x different lines...
Of course not. What is "repeating" _already_ in character mode is using the same character code multiple times for its all scanlines. You can't repeat the character line itself then (it would be repeating the repeated stuff) ... In pixel mode the situation is different, as Nick "directly" reads/displays pixels, while in ch modes, there is an indirect mode: character code indexed font data is transferred to pixels (how? depending in colour mode of course) ... And here "character code" is same for the given column of the given character line, but font data is not (of course).
Well, it's my best understanding of the topic, at least!
-
It is actually possible to use ALTIND0/ALTIND1 in all video modes, including even PIXEL modes. Unlike LSBALT and MSBALT, these do not clear the bits they use, so it is possible to have 4 pairs of colors in 2-color CH256 mode:
- characters 0 to 63 will use colors 0 and 1
- characters 64 to 127 will use colors 4 and 5 (ALTIND0)
- characters 128 to 191 will use colors 2 and 3 (ALTIND1)
- characters 192 to 255 will use colors 6 and 7 (ALTIND0+ALTIND1)
And in 4-color character modes this becomes:
- colors 0,1,2,3 for characters 0-63
- colors 4,5,6,7 for characters 64-127
- colors 2,3,2,3 for characters 128-191
- colors 6,7,6,7 for characters 192-255
?
Or is there a "magic" trick to make the last two fours more useful...?
I would really hope there was a way to have all the fours different, but that's just impossible...
-
And in 4-color character modes this becomes:
- colors 0,1,2,3 for characters 0-63
- colors 4,5,6,7 for characters 64-127
- colors 2,3,2,3 for characters 128-191
- colors 6,7,6,7 for characters 192-255
?
Or is there a "magic" trick to make the last two fours more useful...?
I would really hope there is a way to have all fours different, but I guess that's impossible...
in the Gracha Editor I use 2*4 color char mode. sad, there are no other useable mode (masked bits...)
-
So I guess the only way to get four sets (well...somewhat) would be to use char128 mode and have an alternative set of blocks with either color inversion/swap or dither...and use ALTIND0...
-
So I guess the only way to get four sets (well...somewhat) would be to use char128 mode and have an alternative set of blocks with either color inversion/swap or dither...and use ALTIND0...
maybe useable for some graph styles... strongly dithered artistic styles maybe
or make an intellingent gfx converter that can convert the graphics to these bit-masked modes
-
And in 4-color character modes this becomes:
- colors 0,1,2,3 for characters 0-63
- colors 4,5,6,7 for characters 64-127
- colors 2,3,2,3 for characters 128-191
- colors 6,7,6,7 for characters 192-255
?
Yes, and without ALTIND1, the second half of the character set is again 0,1,2,3 and then 4,5,6,7. It is not possible to use more colors than that with ALTIND0 and ALTIND1, these just perform OR 4 and OR 2 operation on the color.