OriginalJohn Posted April 10 Share Posted April 10 I was looking at the color options for chars and sprites. Chars (8x8) you can define a color for the each of the rows. For sprites (16x16) if seems you can only define one color. Is there a way to create a sprite with multiple colors (define each pixel color)? Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted April 10 Share Posted April 10 3 minutes ago, OriginalJohn said: I was looking at the color options for chars and sprites. Chars (8x8) you can define a color for the each of the rows. For sprites (16x16) if seems you can only define one color. Is there a way to create a sprite with multiple colors (define each pixel color)? Not an expert answer. But, the most common technique is layering single color sprites on top of eachother. Quote Link to comment Share on other sites More sharing options...
OriginalJohn Posted April 10 Share Posted April 10 2 minutes ago, Gemintronic said: Not an expert answer. But, the most common technique is layering single color sprites on top of eachother. Thanks! I'll give that a shot! 1 Quote Link to comment Share on other sites More sharing options...
Jess Ragan Posted April 10 Share Posted April 10 My understanding is that you can have eight sprites active at once, but the first four take priority. So if there's a lot of activity in one line, those four sprites will be drawn first, and the last four will be most subject to flicker. It seems most logical to assign the extra color to one of the last four sprites, because they'll be the most expendable. I'm noticing that BASIC files can be nested with INCLUDE, resulting in less mess and a more modular design. If you, say, wanted to create a custom font, you could do that inside another BASIC file, and reference that file in your main program. If you wanted to use the custom font in several games, you could reference that file in whatever program that needs it, saving you time and keeping the main program tidy. My question is this: is there an ASCII table specifically for the ColecoVision? What addresses would I need to use to change the system's font? I'm not crazy about the ColecoVision font; it makes every game look like Space Invaders, even when it's not Space Invaders. Quote Link to comment Share on other sites More sharing options...
Jess Ragan Posted April 10 Share Posted April 10 Wait wait, there are 256 total 8x8 pixel characters, right? Are they part of the ASCII code? Could you technically just PRINT them on the screen with the appropriate ASCII code, as if they were text? Quote Link to comment Share on other sites More sharing options...
+nanochess Posted April 10 Author Share Posted April 10 4 hours ago, Jess Ragan said: My understanding is that you can have eight sprites active at once, but the first four take priority. So if there's a lot of activity in one line, those four sprites will be drawn first, and the last four will be most subject to flicker. It seems most logical to assign the extra color to one of the last four sprites, because they'll be the most expendable. I'm noticing that BASIC files can be nested with INCLUDE, resulting in less mess and a more modular design. If you, say, wanted to create a custom font, you could do that inside another BASIC file, and reference that file in your main program. If you wanted to use the custom font in several games, you could reference that file in whatever program that needs it, saving you time and keeping the main program tidy. My question is this: is there an ASCII table specifically for the ColecoVision? What addresses would I need to use to change the system's font? I'm not crazy about the ColecoVision font; it makes every game look like Space Invaders, even when it's not Space Invaders. You can have 32 sprites at the same time, but if you put more than 4 in a row the other sprites will disappear or there will be some flicker. 1 hour ago, Jess Ragan said: Wait wait, there are 256 total 8x8 pixel characters, right? Are they part of the ASCII code? Could you technically just PRINT them on the screen with the appropriate ASCII code, as if they were text? CVBasic starts in MODE 0. In this mode, it loads the ASCII letters and signs in the range 32-127. Given these characters are loaded in VRAM, nothing prevents you from redefining them or reusing the character space to draw graphics. In fact in the picture I show a few posts above, Monkey Moon draws the level using the lowercase letters redefined to ladders and girders. Quote Link to comment Share on other sites More sharing options...
Pixelboy Posted April 10 Share Posted April 10 3 hours ago, nanochess said: CVBasic starts in MODE 0. In this mode, it loads the ASCII letters and signs in the range 32-127. ... and those "default" letters and symbols are stored in the Coleco BIOS, by the way. 1 Quote Link to comment Share on other sites More sharing options...
OriginalJohn Posted April 10 Share Posted April 10 I don't know if this is the appropriate place to ask, but here goes. If I define two sprites each with their own label, DEFINE SPRITE 0,1,sprite1 DEFINE SPRITE 1,1,sprite2 Executing the code and attempting to display one in the upper left and one in the middle of the screen. SPRITE 0, 0, 0, 0, 2 SPRITE 1, 80, 120, 0, 2 Results in the same sprite appearing in each location instead of the one which is defined as sprite2. What am I doing wrong? Quote Link to comment Share on other sites More sharing options...
+nanochess Posted April 10 Author Share Posted April 10 2 hours ago, OriginalJohn said: I don't know if this is the appropriate place to ask, but here goes. If I define two sprites each with their own label, DEFINE SPRITE 0,1,sprite1 DEFINE SPRITE 1,1,sprite2 Executing the code and attempting to display one in the upper left and one in the middle of the screen. SPRITE 0, 0, 0, 0, 2 SPRITE 1, 80, 120, 0, 2 Results in the same sprite appearing in each location instead of the one which is defined as sprite2. What am I doing wrong? The second statement should be: SPRITE 1,80,120,4,2 Because the sprite definition number is multiplied by 4. Quote Link to comment Share on other sites More sharing options...
OriginalJohn Posted April 10 Share Posted April 10 (edited) 51 minutes ago, nanochess said: The second statement should be: SPRITE 1,80,120,4,2 Because the sprite definition number is multiplied by 4. Thank you! Edited April 10 by OriginalJohn Quote Link to comment Share on other sites More sharing options...
Jess Ragan Posted April 11 Share Posted April 11 In the words of Archimedes, HELL YEAH. I was weary of the font on the ColecoVision, but this adds a touch of class to it. Now I know how to create a custom font on this system, and so do you... just replace the bitmaps with whatever you please. The colors on the bottom can likewise be adjusted, but I chose a grey edge for the tops and bottoms of each letter, to give them a more metallic look. It's a thing Compile used to do on the MSX, as I recall. (The Z is funky. I'm not sure why.) Okay, so question. If I put this as an include in another BASIC program, it's not going to take up 12K of my total allotted space, is it? I presume it's just going to apply my custom graphics, terminate, and come back to the program itself with no significant loss in available storage. All that's just going straight to the VRAM, and it was already used by the BIOS in the first place. bellafonte.bas bellafonte.rom 1 Quote Link to comment Share on other sites More sharing options...
Jess Ragan Posted April 11 Share Posted April 11 Okay, okay, I think I see the problem. Had to add one to the CHAR and COLOR DEFINE count. Man, this is so nifty! Now I wanna do a whole bunch of stuff with the ColecoVision! bellafonte.bas bellafonte.rom 1 Quote Link to comment Share on other sites More sharing options...
+nanochess Posted April 11 Author Share Posted April 11 1 hour ago, Jess Ragan said: In the words of Archimedes, HELL YEAH. I was weary of the font on the ColecoVision, but this adds a touch of class to it. Now I know how to create a custom font on this system, and so do you... just replace the bitmaps with whatever you please. The colors on the bottom can likewise be adjusted, but I chose a grey edge for the tops and bottoms of each letter, to give them a more metallic look. It's a thing Compile used to do on the MSX, as I recall. (The Z is funky. I'm not sure why.) Okay, so question. If I put this as an include in another BASIC program, it's not going to take up 12K of my total allotted space, is it? I presume it's just going to apply my custom graphics, terminate, and come back to the program itself with no significant loss in available storage. All that's just going straight to the VRAM, and it was already used by the BIOS in the first place. If you include this in your main program, the size of the final ROM will only grow by 2K, more or less the size of the ROM you are generating now. Another option is to draw your font in BMP format, including color, and process this with TMSColor using the tiles option and the Pletter compression. You can probably get it down to 800 bytes or so. Quote Link to comment Share on other sites More sharing options...
Jess Ragan Posted April 11 Share Posted April 11 2K? I can live with a margin like that. I haven't learned how to use TMSColor yet. It might be a necessity for the more complex graphics I'd like to use in a project. Quote Link to comment Share on other sites More sharing options...
Révo Posted April 11 Share Posted April 11 Hey, I'm looking for a way to clean text (in some area not all), as you can see I'm using space after text to clean the text before but this is taking lot of space in the ROM. Cheers. Quote Link to comment Share on other sites More sharing options...
+5-11under Posted April 11 Share Posted April 11 4 hours ago, Révo said: Hey, I'm looking for a way to clean text (in some area not all), as you can see I'm using space after text to clean the text before but this is taking lot of space in the ROM. Cheers. You could make a little subroutine to clear that area of the screen before doing any printing. Also, I think the money logic needs a bit of cleaning up. For instance, if Alf costs 9, then <9 is not enough money, but >8 is enough (you've got >9, which means you'd need 10). Quote Link to comment Share on other sites More sharing options...
abeker Posted April 11 Share Posted April 11 Oh lol, thanks to the code above I just realized that I don't use the PROCEDURE statement at all even though according to the manual it's required to create routines that can be called with GOSUB. I wonder if it's really required to guarantee RETURN'ing works correctly, or maybe I'm just lucky Quote Link to comment Share on other sites More sharing options...
+nanochess Posted April 11 Author Share Posted April 11 10 hours ago, Révo said: Hey, I'm looking for a way to clean text (in some area not all), as you can see I'm using space after text to clean the text before but this is taking lot of space in the ROM. Cheers. Use this code for cleaning parts of the screen: FOR #c = $1800 + 128 TO $1800 + 191 VPOKE #c,32 NEXT #c I used separated constants so you can see the starting and ending positions on the screen. And yep, it will save you a lot of bytes! Quote Link to comment Share on other sites More sharing options...
+nanochess Posted April 11 Author Share Posted April 11 2 hours ago, abeker said: Oh lol, thanks to the code above I just realized that I don't use the PROCEDURE statement at all even though according to the manual it's required to create routines that can be called with GOSUB. I wonder if it's really required to guarantee RETURN'ing works correctly, or maybe I'm just lucky I don't have yet added warnings for this. Unlike Intellivision, in Z80 there's no required stack frame so it doesn't crash. But for syntax and maybe future optimization I'll require GOSUB to go to a PROCEDURE. Quote Link to comment Share on other sites More sharing options...
+nanochess Posted April 11 Author Share Posted April 11 I just updated to v0.4.3, some of the new changes are: * DATA statements can now use constant expressions and VARPTR (for addresses). * Optimized access to arrays when using constant index (so fast as variables). * Implemented USR and CALL to simplify calling assembler language. * Added support for formatted PRINT with leading zeros or spaces, for example, PRINT AT 5,"Score:",<5>#score * Super Game Module support added (using --sgm option on compilation). * It includes the CVBasic source code in the ASM output so you can see how things are compiled. Available in the first post. 2 1 Quote Link to comment Share on other sites More sharing options...
Jess Ragan Posted April 11 Share Posted April 11 Hot damn! Super Game Module support, too? What's that going to give developers? 128K of RAM and the extra sound channels of the MSX? Quote Link to comment Share on other sites More sharing options...
+nanochess Posted April 11 Author Share Posted April 11 1 hour ago, Jess Ragan said: Hot damn! Super Game Module support, too? What's that going to give developers? 128K of RAM and the extra sound channels of the MSX? 24K of RAM to get you also ADAM compatibility and SOUND 5-9 gets you the SGM sound channels. I forgot to initialize the SGM, so in the meanwhile, you should start your SGM programs with: SOUND 5,,0 SOUND 6,,0 SOUND 7,,0 SOUND 9,,$B8 Or use this updated cvbasic_epilogue.asm cvbasic_epilogue.asm 1 Quote Link to comment Share on other sites More sharing options...
Jess Ragan Posted April 12 Share Posted April 12 TMScolor is a real time saver, I'll tell you h'what. So! I just made a thing. It's not a game, but there's animation, so that's a step in the right direction. The ROM should run in anything that can play ColecoVision games. (Also, phew. Even with TMScolor, this took some time.) antiqueovision.rom 1 Quote Link to comment Share on other sites More sharing options...
+nanochess Posted April 12 Author Share Posted April 12 1 hour ago, Jess Ragan said: TMScolor is a real time saver, I'll tell you h'what. So! I just made a thing. It's not a game, but there's animation, so that's a step in the right direction. The ROM should run in anything that can play ColecoVision games. (Also, phew. Even with TMScolor, this took some time.) antiqueovision.rom 3.16 kB · 1 download Awesome animation! 👏👏👏 Quote Link to comment Share on other sites More sharing options...
slydc Posted April 12 Share Posted April 12 A new update of CVbasic ? You're the man Oscar! And the animation of Jess, really great! Well i have done a small slideshow of 5 pictures and this is the second version as the first one there was a different color screen in between the pictures but now that's corrected. It's not much but it's a start, hope some of you will like it. slideshow02.rom 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.