Kinda a weird issue

[Kiwi]

I didn't want to show this too early. It is a sequel to the Colecovision version of Star Ocean. You can get the Colecovision ROM here .

 

 

The text works as it print out a letter a frame. I am using the restore/read function to print individual letters since that made it easier to point at the script and then write it out.

restore sampleline00
textcolor=5
gosub WriteWord

WriteWord:procedure

for i=0 to 59
read #temp
#temp=#temp*8
poke($200+i,#temp+1+textcolor)
wait
'wait
next i

while i!=0
if cont.b0 then i=0
wend
return
end

sampleline00:
data "HI LITTLE STAR, WHATCAN I DO FOR YOU?AREYOU LOST OR CRAZY???"

I applied math to it to convert data to printable letters and apply colors.

 

 

Only downside I couldn't use

 

restore text(pointer) to offset data.

 

So the right image is what I intent it to do and works in Nostagia, but fails in jzintv. I haven't tried it on LTO flash and I'm confident it'll fail on the real thing. Since the spell list have swapable magic, restore/read won't work due to lack of array function. So I programmed this.

for j=0 to 5
wait
for x=0 to 99
'forces to waste cycles til screen is on to print letter or it will corrupt the screen data
next x
x=MagicList(j)
for i=0 to 7
#temp=peek MagicName(i+x*
#temp=#temp*8

poke($200+84+i+j*20,#temp+7)

next i
print at 94+j*20 color 7,<2> MagicMPlist(magiclevel+x*10)
next j

and the list

MagicName:
DATA "   --   "
DATA "STARSHOT"
DATA "HEALING "
DATA "TWINSHOT"
DATA "STARRAIN"
DATA "   --   "

I'm not sure if there's an easier way to print on screen by using list/pointers instead of print function

 

[intvnut]

The GROM character set is offset by $20 from ASCII, so you need to subtract this bias off, assuming DATA doesn't do that for you. (I'm at work, can't test.)

 

Not sure why Nostalgia is displaying it correctly. If it is, then there must be other games it displays incorrectly. It looks like you're in FG/BG mode, and that only has access to the first 64 GROM characters (upper case alphabetics only, for example), so with the $20 bias, you're probably wrapping back around into the punctuation and such.

 

Try changing your code like so:

.

#temp = (peek MagicName(i+x*) - $20

[Kiwi]

I did several tests on real hardware, it return the same value. For example, it returned number 31 which prints ?. If I make it waste more cycle, different character change, but same value.

So the menu shows

...????????

????????

????????...

I'm thinking the vblank1 is to use peek to read the data from ROM, and poke it when the screen is on. Then the CPU isn't giving the value to poke since the STIC is using the 16-bit RAM value if I understood how the Intellivision works. Hmm.... 3 different results from Nostagia, jzintv, and LTO Flash. However, the dialogue text using read/restore function printed correctly. And the game behave the same as it was in jzintv. I will have to try again tomorrow when my brain isn't on fire.

Edited February 9, 2017 by Kiwi

[intvnut]

I'm thinking the vblank1 is to use peek to read the data from ROM, and poke it when the screen is on.

 

VBlank doesn't come into this at all. The ROM is always visible, as is the BACKTAB. You're not accessing the STIC, GRAM or GROM directly. At least you shouldn't be.

 

I just realized the error. *headslap*

 

Compare this:

.

#temp = (peek MagicName(i+x*) - $20

.

to this:

.

#temp = MagicName(i+x* - $20

.

See what's missing?

 

If you're using array notation to access data tables, you don't need to PEEK. What your code was actually doing was PEEKing at the address determined by the letter you were trying to display! For example, MagicNum( 8 ) should give you 'S', which has the ASCII value 73. On the other hand, PEEK MagicNum( 8 )will give you whatever is in address 73. And that address is off in STIC-space.

 

Oops!

Edited February 9, 2017 by intvnut

[Kiwi]

DOH!!!

 

Removing peek, and now it is displaying the spell names on the magic menu screen correctly in jzintv and possibly on the Intellivision. Yeah, I was trying to grab the letters off of the ROM table.

 

Thank you so much for helping.

[Rev]

Cool

[Kiwi]

I should show more of it...

 

 

The video run at 30 fps on youtube, so TWINSHOT and STARRAIN spells have their virtual sprite drop. Still very early.

 

I'll probably release the ROM when completed like I did for the Colecovision version.

 

GRAM information if someone's curious and have asked before:

 

0-31(first 13 is pass through) for the background

32-33 redefining Starmi sprite

34-35 weapon

36-43 for the star and 7 orbs graphic. Redefiniting orb will buy back 5 cards, for now, I will leave it.

44-47 Magic Icon/animation frame

48-55 8 cards for enemy 1

56-63 8 cards for enemy 2 (still need to figure the logic to tell it to look here if loaded)

[+nanochess]

I should show more of it...

 

 

The video run at 30 fps on youtube, so TWINSHOT and STARRAIN spells have their virtual sprite drop. Still very early.

 

I'll probably release the ROM when completed like I did for the Colecovision version.

 

GRAM information if someone's curious and have asked before:

 

0-31(first 13 is pass through) for the background

32-33 redefining Starmi sprite

34-35 weapon

36-43 for the star and 7 orbs graphic. Redefiniting orb will buy back 5 cards, for now, I will leave it.

44-47 Magic Icon/animation frame

48-55 8 cards for enemy 1

56-63 8 cards for enemy 2 (still need to figure the logic to tell it to look here if loaded)

 

I'm bad for playing RPG, but I would play this one when finished nice work!

[GroovyBee]

I should show more of it...

Looks good so far. I think the player's avatar needs to be a higher contrast colour compared to the background. He seems to get lost in the backgrounds to me.

[+DZ-Jay]

Looks good.

 

 

GRAM information if someone's curious and have asked before:

 

0-31(first 13 is pass through) for the background

32-33 redefining Starmi sprite

34-35 weapon

36-43 for the star and 7 orbs graphic. Redefiniting orb will buy back 5 cards, for now, I will leave it.

44-47 Magic Icon/animation frame

48-55 8 cards for enemy 1

56-63 8 cards for enemy 2 (still need to figure the logic to tell it to look here if loaded)

 

Interesting. I see that loading all animation frames into GRAM is a very common technique around here. I usually cycle the GRAM cards and only allocate one or two cards per sprite or animation object (depending on 8x8 or 8x16 resolution) and update the card from ROM as necessary.

 

In my experience, if you update only "dirty" tiles, there is plenty of time during VBLANK to animate all objects. I prefer this method to the other one because it leaves more GRAM free for static background detail.

 

-dZ.

[+DZ-Jay]

Looks good so far. I think the player's avatar needs to be a higher contrast colour compared to the background. He seems to get lost in the backgrounds to me.

 

I think it's also because the backgrounds are very "busy." May I suggest being more subtle with the detail instead of the checker-board pattern of light and dark green? It calls out too much attention to itself and distracts from the player's avatar and the action.

[GroovyBee]

You might also want to consider using more background colours in order to have a less "raw" ASCII looking stats/spells pop-up e.g.

 

Edited February 15, 2017 by GroovyBee

[+DZ-Jay]

You might also want to consider using more background colours in order to have a less "raw" ASCII looking stats/spells pop-up e.g.

 

spells.png

 

That looks pretty cool.

 

Also, if you were to use Color Stack (which your backgrounds would support), then you have access to GROM cards, which will allow you to create a "border" outline around the pop-up box.

 

If you need help converting your graphics to Color Stack, let us know.

 

-dZ.

[+DZ-Jay]

 

I'm bad for playing RPG, but I would play this one when finished nice work!

 

Same for me: I don't really play RPGs, but I love Super Mario Bros. games, and this one has enough of that charm to interest me.

 

-dZ.

[+Tarzilla]

Looks good.

 

 

 

Interesting. I see that loading all animation frames into GRAM is a very common technique around here. I usually cycle the GRAM cards and only allocate one or two cards per sprite or animation object (depending on 8x8 or 8x16 resolution) and update the card from ROM as necessary.

 

In my experience, if you update only "dirty" tiles, there is plenty of time during VBLANK to animate all objects. I prefer this method to the other one because it leaves more GRAM free for static background detail.

 

-dZ.

Between DEFINE and DEFINE ALTERNATE and careful ordering of the BITMAP statements you should not have to waste multiple GRAM slots for animation frames...in most cases...

[+Tarzilla]

Another thing to remember is:

IntyBASIC supports the extra RAM available on the boards from Harvey and Joe.

You lose some ROM space but the freedom of ram would let you save the screen, or part of it, overlay whatever, then restore it, for instance

[+DZ-Jay]

Between DEFINE and DEFINE ALTERNATE and careful ordering of the BITMAP statements you should not have to waste multiple GRAM slots for animation frames...in most cases...

Thanks for the info, I wouldn't have known how to do this "natively" in IntyBASIC.

 

I wonder if it would be useful to create an example of a simple "sprite animation driver" in IntyBASIC to show how this could be done.

 

The way I do this in my own framework is to dedicate a single byte as a "dirty status" bitmap for all 8 objects. I have a function that takes as argument a sprite Object ID (i.e., its index) and converts it to a 2^n value and sets it's dirty flag.

 

My animation engine runs on every iteration of the game loop determining which objects need to be updated based on their frame-rate (described as an 8.8 fractional value, very similar to the way sub-pixel movement is done).

 

Furthermore, each object has an "Object Record" which consists of a pointer to the animation sequence data, the total number of frames, a frame counter, a pointer to its allocated GRAM, and it's animation frame-rate (among other information).

 

To update an object, we just advance it's animation sequence counter (looping at max) and compose a pointer to the next frame card in ROM. When an object is updated the SetDirtyFlag(id) function is called to mark it for update.

 

Then in the ISR, it shifts through the Dirty Status bitmap and for every bit set, it copies the data at the updated card pointer of the object into its allocated GRAM.

 

Like this, I am able to animate a surprising number of objects simultaneously, since in practice very few are updated on every single frame. Plus, the fractional "sub-frame rate" allows for a rather granular and varied animation rate across all objects.

 

The best part is that it works just the same whether your object has 2 frames or 20, opening up the doors for rich animations.

 

dZ.

[+Tarzilla]

This isn't a proper sprite engine with "dirty bits" but it does illustrate a way of using DEFINE and DEFINE ALTERNATE to change GRAM on the fly to free up GRAM slots.

[Click to animate]

 

The entire thing only uses 6 cards at a time, 2 for the background, 1 for the poop, 1 for the birds and one for the player character. By carefully interleaving the bird and Krab BITMAPS, One call to DEFINE can update both the birds and the player. Push the button

 

Of note is the UpdateGram procedure, it decides what DEFINE to use

and DEFINE ALTERNATE is called to update the crappy poop animation frames. A better illustration is the waterfalls in Zyx, one level has a waterfall almost as big as the screen, animated with just one DEFINE.

 

There are a possible 4 birds, You could easily devote one card slot to each flying thing and give them different graphic designs, interleaving the frames the same way BIRD1 and KRAB1 are in the example.

 

There is no sound, collisions, title or game over, I wrote it over an hour or two last night before going to bed. Maybe I'll spend another couple of hours and finish it so we can have a runner up for worst game of 2017 (a new category in the GOTY)

 

 

 

 

 

 

 

KrabKoveKafe.zip

[carlsson]

We might get closer and closer to an Intellivision Crap Game Compo after all...

[+Tarzilla]

We might get closer and closer to an Intellivision Crap Game Compo after all...

I'm just hoping Rev doesn't see the Krab post and pester me to release it on cart as part of his quest to release the worst game of the year...

[Kiwi]

Thanks for the info, I wouldn't have known how to do this "natively" in IntyBASIC.

 

Then in the ISR, it shifts through the Dirty Status bitmap and for every bit set, it copies the data at the updated card pointer of the object into its allocated GRAM.

 

dZ.

poke data directly into the GRAM will update the GRAM is another method.

 

for i=0 to 15

poke $GRAMSLOT0(i),data(i)

next i

 

Only effective if use directly after wait. define and alter define will wait til 'wait' statement is hit and then push data to GRAM. Who know, you may be in Vblank1 or Vblank2 in the middle of your intybasic program. Having 5 blobs on screen and using twinshots magic slowed the game down. I assume blob 1 and blob 5 would be updated while blob 2 and 4 would be a box if it is POKEd in.

 

Tower Inferno uses define/define alternate due to your suggestion Tarzilla. There's 2 waits in the main loop to split up the load. I used flipper variable to use 2 more alt/define statements.

 

First loop mainly focus on the character movement/collision, water movement. Update all object sprites, exception the boss. Water tank use define alternate in this loop and update on queue. I assuming I'll use define for the main char later in development because I don't like drawing human sprites for some reason.

 

Second loop mainly focus on object behavior. Boss sprite data get updated can take over sprite 6,7 for a frame causing it to multiplexing when object slot 5 and 6 x position isn't 0. The fireballs probably take the most cpu cycle, but no hint of slowdown. I use a variable that flip 0 in one complete loop, and then 1 one complete loop, in which I slowed down the fire animation and can use this to make the enemies move slower. It also allow me to use 4 define/alt in that half of the loop. The fire animation is consistence, so the card slot 23 is update every 4 frame with alt define and the 2 fiery enemies' sprites are contingency so 4(4 card free for more fiery sprites) cards are updated using the define statement. Boss animation frame is updated every 4 with define when flipper = 1. So I have alt define free when flipper = 1. I wanted the boss to be more expressive but I'll worry about that later.

 

Example for cheapo boss animation would be.

 

Boss1:procedure

if flipper=1 then

if bossanim=0 then define 16,2,bossframe1

if bossanim=1 then define 16,2,bossframe2

if bossanim=2 then define 16,2,bossframe3

if bossanim=3 then define 16,2,bossframe4

bossanim=bossanim+1

if bossanim>3 then bossanim=0

end if

 

I think if I remember, define could use array right? I could

 

define 16,2,bossanimation(bossframe)

 

data 0,16,32,48

 

The gameloop is set up similar to Tower Inferno. Except the main character is redefining cards in the first loop. I do plan to have animated tile if needed. Magic, Starrain could use 16 high card to cover more of the screen and be redefined since it is in it own loop. Boss graphic would be updated in the 2nd loop. I'll probably redefine the orbs too to free up 3 cards and use that toward GUI graphics.

 

I preferred to work with BG/FG mode. It allow me to make more complicated tiles and use another color for that tilebased object like the trees for example. Predefined GROM is a bit restrictive, but lower case usage letters would be nice. And GROM graphics also can't use pastel color. Right? Color-square is nice, but not really useful. I went with flip screen so it's easier to spawn objects and not have it kite to overload the Intellivision with a bunch of multiplex'd MOBs. Working on a multi-directional scrolling game on the Colecovision made me realize that you also have to memorize the objects that have spawn and don't respawn the same object. That one had 8 single color sprites, and 4 double color sprites. I'll complete that level one day... Oy. I gone way off track! Plus it is easier for me to make bg/fg graphics in Tilestudio to port over into the game by IntyCOLOR. There will be multiple tileset in this game. There's 2 so far. I have to draw 3 tileset more tonight. And have to draw the tall top tree area and the beach one too. So that's 160 cards to produce. Not to mention the object sprites. I'm hoping to fit it all on one 84KB cart. Else, I have to figure out to make decompression schemes.

 

The spell list look really good. I'll have to figure out how to merge text data AND color table into one card.

Edited February 17, 2017 by Kiwi

[+Tarzilla]

Boss1:procedure

if flipper=1 then

if bossanim=0 then define 16,2,bossframe1

if bossanim=1 then define 16,2,bossframe2

if bossanim=2 then define 16,2,bossframe3

if bossanim=3 then define 16,2,bossframe4

bossanim=bossanim+1

if bossanim>3 then bossanim=0

end if

 

I don't believe that is that efficient. It will always compare 4 IF conditions.

Instead you can use

 

 

ON bossanim goto

Or

On bossanim Gosub

[GroovyBee]

If you want maximum efficiency, then this is the way to go :-

const BOSS1_HEIGHT=8    ' For an 8 pixels high boss, use a value of 4.
const BOSS1_FRAMES=4    ' Number of animation frames (must be a power of 2).
const BOSS1_FRAME_MASK=(BOSS1_FRAMES*BOSS1_HEIGHT)-1

Boss1: procedure
    if flipper=1 then
        define 16,2,varptr Boss1Frames(bossAnim)
        bossAnim=bossAnim+BOSS1_HEIGHT
        bossAnim=bossAnim and BOSS1_FRAME_MASK
    end if
    end

Boss1Frames:
Boss1Frame1:
    data $c0c0,$c0c0,$c0c0,$c0c0
    data $c0c0,$c0c0,$c0c0,$c0c0
Boss1Frame2:
    data $3030,$3030,$3030,$3030
    data $3030,$3030,$3030,$3030
Boss1Frame3:
    data $0c0c,$0c0c,$0c0c,$0c0c
    data $0c0c,$0c0c,$0c0c,$0c0c
Boss1Frame4:
    data $0303,$0303,$0303,$0303
    data $0303,$0303,$0303,$0303

Edit: The original routine (not including data) was 93 decles and this one is only 34. Edited February 17, 2017 by GroovyBee

[+DZ-Jay]

I preferred to work with BG/FG mode. It allow me to make more complicated tiles and use another color for that tilebased object like the trees for example. Predefined GROM is a bit restrictive, but lower case usage letters would be nice. And GROM graphics also can't use pastel color. Right? Color-square is nice, but not really useful.

 

So far, we've managed to show you that Color Stack can do everything you've tried to do in FG/BG, so it's really not as limited as you imagine.

 

Also, I am not talking about using GROM graphics to draw your background, I am talking about enhancing your detail with GROM graphic cards. For instance, in my experience, when I rip an image into tiles, I am able to replace some of them with GROM cards and conserve GRAM. You'd be surprised how effective this is. In fact, even a for solid block of colour you would have to waste an entire GRAM card if you were using FG/BG.

 

It is true that GROM graphics cannot use pastel colours, but there are ways around that by using the Color Stack creatively.

 

And finally... Colored Square mode is crap. Nobody should use it.

 

-dZ.

[GroovyBee]

And finally... Colored Square mode is crap. Nobody should use it.