IntyBASIC compiler v0.7 (now with IntyColor)

[Cybearg]

30 cards?

If the score takes 6 digits, then for a side scrolling game, you would need 7 cards to display it in unshifted or shifted state.

But since a DEFINE statement can only load in one set of cards at a time and I wouldn't know which numbers were being used, I'd need the full 10-card set of all possible digits, 0-9, plus more for the bookends, otherwise the first digit and the last one would have stray pixels hanging off the ends. For zero, for instance, I have 8 frames for each number, so 0 is like this:

 

... But since all frames except index 0 have half the 0 going off the screen and half of a new 0 coming in, I'd need bookends on the left and right that finished this two-sided card without starting a new one, or else the score would always have trailing, empty pixels on its edges.

 

Am I misunderstanding? What should the cards be like?

 

(Do you really need to see the score all the time, though.?)

Maybe not, although it's pretty weird to not have the score displayed in a side-scroller. There are other HUD elements I'd want to display, though, and while I COULD also display them in other ways (or rely on information given only in the pause screen or something), those alternatives are clumsy compared to a GUI and I think that they would detract from the ease of use of the final game. Edited September 28, 2014 by Cybearg

[catsfolly]

But since a DEFINE statement can only load in one set of cards at a time and I wouldn't know which numbers were being used, I'd need the full 10-card set of all possible digits, 0-9, plus more for the bookends, otherwise the first digit and the last one would have stray pixels hanging off the ends. For zero, for instance, I have 8 frames for each number, so 0 is like this: scroll_f1.gif

 

... But since all frames except index 0 have half the 0 going off the screen and half of a new 0 coming in, I'd need bookends on the left and right that finished this two-sided card without starting a new one, or else the score would always have trailing, empty pixels on its edges.

 

Am I misunderstanding? What should the cards be like?

 

Maybe not, although it's pretty weird to not have the score displayed in a side-scroller. There are other HUD elements I'd want to display, though, and while I COULD also display them in other ways (or rely on information given only in the pause screen or something), those alternatives are clumsy compared to a GUI and I think that they would detract from the ease of use of the final game.

Okay. Let's imagine we have a zero, with a space in front of it. This is our character set if the horizontal scroll is set to 0.

If we set the horizontal scroll to 1, then an extra scan line is added to the left of the screen, and all the characters shift one bit to the right.

To counteract this, we need characters with all the bits shifted 1 bit to the LEFT.

If we set the horizontal scroll to 2, we need to shift the characters 2 bits to the left to counteract the effect.

This continues up to 7, which would be shifted 7 bits to the left. So the set of characters we would need to display a counterscrolled

zero is:

0 offset
"........" "........"
"........" "#######."
"........" "##...##."
"........" "##.#.##."
"........" "##.#.##."
"........" "##...##."
"........" "#######."
"........" "........"
1 offset
"........" "........"
".......#" "######.."
".......#" "#...##.."
".......#" "#.#.##.."
".......#" "#.#.##.."
".......#" "#...##.."
".......#" "######.."
"........" "........"
2 offset
"........" "........"
"......##" "#####..."
"......##" "...##..."
"......##" ".#.##..."
"......##" ".#.##..."
"......##" "...##..."
"......##" "#####..."
"........" "........"
3 offset
"........" "........"
".....###" "####...."
".....##." "..##...."
".....##." "#.##...."
".....##." "#.##...."
".....##." "..##...."
".....###" "####...."
"........" "........"
4 offset
"........" "........"
"....####" "###....."
"....##.." ".##....."
"....##.#" ".##....."
"....##.#" ".##....."
"....##.." ".##....."
"....####" "###....."
"........" "........"
5 offset
"........" "........"
"...#####" "##......"
"...##..." "##......"
"...##.#." "##......"
"...##.#." "##......"
"...##..." "##......"
"...#####" "##......"
"........" "........"
6 offset
"........" "........"
"..######" "#......."
"..##...#" "#......."
"..##.#.#" "#......."
"..##.#.#" "#......."
"..##...#" "#......."
"..######" "#......."
"........" "........"
7 offset
"........" "........"
".#######" "........"
".##...##" "........"
".##.#.##" "........"
".##.#.##" "........"
".##...##" "........"
".#######" "........"
"........" "........"

So, for any given scroll register setting we would need 2 characters for each number 0-9, which would be 20 custom characters. Which is more than IntyBasic can usually handle. And we have a space between each character of the score....

 

On the other hand, if we could compute the score first, and then create 7 custom card images representing the shifted image of the score, all we would need to do is send those 7 card to the gram memory.

"........" "........" "........" "........" "........" "........" "........" 
"........" "#######." "...##..." ".######." ".######." ".##..##." ".######."
"........" "##...##." "...##..." ".....##." ".....##." ".##..##." ".##....."
"........" "##.#.##." "...##..." ".....##." ".....##." ".######." ".##....."
"........" "##.#.##." "...##..." ".######." "..#####." ".....##." ".######."
"........" "##...##." "...##..." ".##....." ".....##." ".....##." ".....##."
"........" "#######." "...##..." ".######." ".######." ".....##." ".######."
"........" "........" "........" "........" "........" "........" "........"

(Imagine the score happens to be 12345, and that I typed this image and all the shifted versions...)

The problems are 1. "define" currently requires 16 bit memory, and 2. There isn't enough 16 bit memory in the stock intellivision to create this image. The solutions would be

 

1. Get Nanochess to make an 8 bit version of "define"

2. Patch the epilogue with a custom assembly routine that loads gram from 8 bit ram.

3. Get Nanochess to support cartridge ram (available on some cartridges).

 

One way to need fewer custom cards is to use half wide characters. Since you have to build an image anyway, you could put two characters in a card...

"........" "........" "........""........"
"........" "###..#.." "###.###.""#.#.###."
"........" "#.#..#.." "..#...#.""#.#.#..."
"........" "#.#..#.." "###.###.""###.###."
"........" "#.#..#.." "#.....#.""..#...#."
"........" "#.#..#.." "#.....#.""..#...#."
"........" "###..#.." "###.###.""..#.###."
"........" "........" "........""........"

That way you only have to send 4 custom cards....

 

Check out "Princess Quest" for Intellivision. They are getting away with minimal "hud"...

 

http://atariage.com/forums/topic/225536-princess-quest-for-intellivision/page-6

[Cybearg]

Thanks for the explanation. As you point out, this is really only practical if I could load those cards from RAM. If that was the case, I could have 7 8-byte sections of RAM set aside, load the appropriate numbers into the last 6 8-byte blocks based on the score, then bit-shift the appropriate number of times until the score shows up correctly. This would be even more necessary if two numbers were on the same card. Am I understanding that right?

 

It would be awesome if loading cards from RAM was supported. Also, since I'm sure I'm not alone in this kind of situation, a bit of built-in Assembly to streamline that shifting process would be nice, too. I really don't know Assembly well enough to be efficient with it, which is why I'm using IntyBasic.

 

Could this maybe be put in the future feature list, nanochess?

 

The complication with my game is that, with an action platformer, most of the game indicators can be implied on-screen with things like one's armor disappearing like in Ghosts and Goblins or the player getting bigger and smaller like in Super Mario. Scores can be implied with a number popping on-screen to show how many points the player is getting when finishing off enemies, like Princess Quest there does.

 

The game I have could cut out displaying the score and how many lives the player has left could be displayed before the player begins, like how lives are displayed in Super Mario. However, there needs to be an ammo counter, and that's where it becomes more complicated. I could probably imply it by sacrificing an extra sprite, although that means 5 of the 8 sprites will be devoted to only displaying the player and implied HUD elements. Additionally, quite a few sprites use the two-sprite overlay trick to add additional detail and colors, meaning that many circumstances would come down to the player, a single enemy, and one projectile for each. Doable, but I would much prefer to be able to have two enemies on-screen at once, for additional gameplay possibilities.

 

I could maybe free up a sprite or two by using the flicker effect, particularly for sprites that are using two sprites for extra detail, but I get the sense that's not as acceptable on the Intellivision as it is on the Atari 2600.

[+nanochess]

Thanks for the explanation. As you point out, this is really only practical if I could load those cards from RAM. If that was the case, I could have 7 8-byte sections of RAM set aside, load the appropriate numbers into the last 6 8-byte blocks based on the score, then bit-shift the appropriate number of times until the score shows up correctly. This would be even more necessary if two numbers were on the same card. Am I understanding that right?

 

It would be awesome if loading cards from RAM was supported. Also, since I'm sure I'm not alone in this kind of situation, a bit of built-in Assembly to streamline that shifting process would be nice, too. I really don't know Assembly well enough to be efficient with it, which is why I'm using IntyBasic.

 

Could this maybe be put in the future feature list, nanochess?

 

In fact DEFINE can refer to any label, so you can use a reference to a 16-bit array in RAM (created for example with DIM #G(4) for a single GRAM definition) not yet tested, I'm working from my memories in the road.

 

Anyway I think the bit-shifting and mixing would be too processor intensive.

[Cybearg]

Anyway I think the bit-shifting and mixing would be too processor intensive.

Oh, really? :/ I would have thought that bit shifting would only take a cycle or two a piece.

 

Since there are only 32 16-bit variables available in IntyBasic, there still wouldn't be enough for 7 cards to exist in memory... Although I guess I could use 16 memory positions and handle the cards one at a time, but I can imagine that being very processor-intensive.

Edited September 28, 2014 by Cybearg