Multi-Layer Sprites, where to go for info?

[jdgabbard]

I've seen several of the members have posted their own sprite editors to the forum. It seems most of these allow for editing multiple layers, spitting out the char equivalent for that particular layer. However, I'm not seeing any discussion on how to layer these sprites. I tried several things last night to call each sprite seperately, and then be controlled all at the same time. but only would get garbage displayed. Calling each sprite independently this isn't a problem. So I know it has something to do which the way I am trying to call these. This was all done with XB to be clear, not Assembly.

 

Does anyone have a link they could point me to that discusses layering of sprites? Or, if not, would you be willing to share some example code?

[sometimes99er]

XB can layer sprites, but when it comes to moving them, if you want a perfect result (the layered sprites stay exactly on top of each other), then XB in itself is too slow.

[jdgabbard]

So then layered sprites are best left to assembly is what you're saying. I don't know much when it comes to assembly. Guess I'll have to either learn it, or settle on single color.

 

Although, now I'm tempted to ask, as I've read there are several XB to Assembly compilers out there. Would that speed up the motion, or is there significant residual carried over from the XB?

[+adamantyr]

Let's get some context here...

 

What are you trying to do in Extended BASIC with multi-layered sprites exactly? You know that if you have more than four sprites on a horizontal line, the fifth and above will disappear, right? So it's mainly useful if you only have one moving multi-sprite on screen, and pretty much no others.

 

Using CALL MOTION is right out. It will never keep the two sprites in sync, I've tested that myself in the day. I'm not sure that even using CALL LOCATE works, I think there is a split second where you see one sprite move before the other. One thing you can do is use CALL SPRITE and just re-instantiate the sprites each time at their new location. That (hopefully) means that Extended BASIC will write out all the sprite attributes at once and not call the routine for each sprite, and maybe keep them in better sync. Also, don't do any mathematical operations for the position variables, like Y*8-7 or anything; you want it to be as absolutely fast as possible.

[+adamantyr]

Here is a short sample program... I wrote this to be as quick and dirty as possible. You can still see the first sprite gets moved SLIGHTLY faster than the second.

100 CALL CLEAR :: CALL CHAR(128,"FF818181818181FF007E7E7E7E7E7E00")
110 R=89 :: C=121
120 CALL SPRITE(#1,128,2,R,C,#2,129,16,R,C)
130 CALL KEY(3,K,S) :: IF S=0 THEN 130
140 IF K=11 THEN R=MAX(1,R-4) :: GOTO 120
150 IF K=10 THEN R=MIN(192,R+4) :: GOTO 120
160 IF K=8 THEN C=MAX(1,C-4) :: GOTO 120
170 IF K=9 THEN C=MIN(256,C+4) :: GOTO 120
180 GOTO 130

[jdgabbard]

Adam, I just tested your example, and see exactly what you're referring to. I guess that is where the flickering of sprites in many 8-bit games came from. But I think it is workable. I had not thought of doing it that way.

 

As for context, what I am attempting to do, and after having thought about it a little more your method makes more sense, is write a multi-layer (read: multicolor) sprite for use in a Homebrew game I am playing around with. The idea is sort of a platform type. Getting the sprites to work like I want is just the first, I'm sure, hurdle that I have to jump. I'm of the belief that if you want to learn a new language, write a game. So this is simply a learning process for me. I hadn't used basic in 20 years or so until a month ago. And I was just a young boy then.

[+adamantyr]

Adam, I just tested your example, and see exactly what you're referring to. I guess that is where the flickering of sprites in many 8-bit games came from. But I think it is workable. I had not thought of doing it that way.

 

As for context, what I am attempting to do, and after having thought about it a little more your method makes more sense, is write a multi-layer (read: multicolor) sprite for use in a Homebrew game I am playing around with. The idea is sort of a platform type. Getting the sprites to work like I want is just the first, I'm sure, hurdle that I have to jump. I'm of the belief that if you want to learn a new language, write a game. So this is simply a learning process for me. I hadn't used basic in 20 years or so until a month ago. And I was just a young boy then.

 

Yes, that's exactly where the flickering came from! Even the classic NES could only support 8 sprites on a line at a time. (They could only be a maximum of 8x16 in size, so the 16x16 ones you see are, in fact, two sprites at least side by side.)

 

The solution, which is where the flicker comes from, is to rotate the sprites. You only need each sprite to appear on screen for 1/30 of a second for the human eye to see it, and the processor runs fast enough (mostly) to do the work of rotating them on video frame. The problem is that as you have more sprites, it REALLY starts to tax the system badly... if you've ever played Mega Man and several moving objects came on the screen, the action on screen and even the music and sound would slow WAY down.

 

Very cool to get started again with a homebrew game! Don't let this discourage you, I still enjoy firing up Extended BASIC and writing stuff, even though I'm in the midst of a massive assembly language project.

 

If you're doing a platform game, my suggestion to start with is to try working with a single sprite at first. You CAN write some excellent platform games in XB. The Billy Ball and Flooraway series by R. Truman is one of the most impressive; I don't see those on the Game Shelf yet (I know I sent those to you, Vorticon!) but if you want copies let me know!

[sometimes99er]

... as I've read there are several XB to Assembly compilers out there. Would that speed up the motion, or is there significant residual carried over from the XB?

 

There's the excellent XB compiler XB Game Developers Package by senior_falcon and it should be fast enough. Of course there are trade offs, and the first thing being that variables goes from floating point and turns into integers (numbers that can be written without a fractional component, for example, 21 and -4 are integers, while 9.751 and -2.1 are not).

 

 

[+OLD CS1]

My experience with XB sprite mock-ups for 4anoid is neither LOCATE nor MOTION keeps the sprites in sync.

[jdgabbard]

 

Yes, that's exactly where the flickering came from! Even the classic NES could only support 8 sprites on a line at a time. (They could only be a maximum of 8x16 in size, so the 16x16 ones you see are, in fact, two sprites at least side by side.)

 

The solution, which is where the flicker comes from, is to rotate the sprites. You only need each sprite to appear on screen for 1/30 of a second for the human eye to see it, and the processor runs fast enough (mostly) to do the work of rotating them on video frame. The problem is that as you have more sprites, it REALLY starts to tax the system badly... if you've ever played Mega Man and several moving objects came on the screen, the action on screen and even the music and sound would slow WAY down.

 

Very cool to get started again with a homebrew game! Don't let this discourage you, I still enjoy firing up Extended BASIC and writing stuff, even though I'm in the midst of a massive assembly language project.

 

If you're doing a platform game, my suggestion to start with is to try working with a single sprite at first. You CAN write some excellent platform games in XB. The Billy Ball and Flooraway series by R. Truman is one of the most impressive; I don't see those on the Game Shelf yet (I know I sent those to you, Vorticon!) but if you want copies let me know!

 

Yeah, Mega Man was essential part of my younger (and really older) years of gaming. I don't care what system it's on, I'll play some MM. And honestly, that was a part of the inspiration for the concept I have. I won't go too far into the details. But the idea, and gameplay is somewhat similar, although, in many aspects I'm going for something completely different. So this method would probably fit well, and be a evolutionary throwback, if you will, to some of those games.

 

99er, I'll have to take a look into that. They may help a lot, especially if I end up going with Adam's approach.

[senior_falcon]

 

There's the excellent XB compiler XB Game Developers Package by senior_falcon and it should be fast enough. Of course there are trade offs, and the first thing being that variables goes from floating point and turns into integers (numbers that can be written without a fractional component, for example, 21 and -4 are integers, while 9.751 and -2.1 are not).

 

 

 

Compiled programs can have perfectly synchronized sprites. CALL SPRITE, CALL MOTION, CALL LOCATE, etc. can create or modify multiple sprites in a single CALL. Unlike native XB, the compiler will do the entire CALL before doing a LIMI. (That's what makes auto sprite motion happen.) So if you want to keep them synchronized just be sure to put them all within the same CALL. When testing in XB they will not be perfectly synchronized, but when compiled they will be.

The compiler does not change the speed of the sprites, but gives much tighter control of them

 

[jdgabbard]

I figured as much. However, as I stated above, I haven't delved into Assembly yet. Maybe eventually, but trying to relearn the basics right now. If the compiler can do a pretty good job it may be something I look into. I'd like to eventually learn Assembly, maybe even burn a cart or two if it turns out to be a halfway decent game. But, this is more of a learning project. And I'll probably decide to do the same if/when I sit down with the intent of learning assembly. There is a lot to learn before that happens, so it'll be something that is set on the back burner for now.

[Opry99er]

Welcome to the forum gabbard!!

 

You have some brilliant programmers on this forum, some of whom have already commented here. Ask lots of questions and post up code and the learning can be extremely rapid.

 

Look forward to your upcoming projects.

[jdgabbard]

Welcome to the forum gabbard!!

 

You have some brilliant programmers on this forum, some of whom have already commented here. Ask lots of questions and post up code and the learning can be extremely rapid.

 

Look forward to your upcoming projects.

 

Thanks, Opry. I've actually watched a few of your videos on youtube. Good stuff, man.

[Opry99er]

Well, i am decidedly NOT one of the brilliant programmers I spoke of, but i am definitely glad you got some enjoyment out of the vids.

 

If you're a BBS guy, check out HeatwaveBBS and you can play an "online" BBS game i wrote for the TI.

 

And do stick around. We love new games and ESPECIALLY new game programmers!

[jdgabbard]

Out of curiosity, and mostly because I hate to start another thread just to ask a question, how exactly are string values stored? Are they stored in RAM? The reason why I ask, is the sprites I am designing will have several variations. For example, turning 180 degrees from left to right would be broken up into the left facing charactor, a 45 degree, a 90 degree (screen facing), a 135 degree, and lastly a 180 degree graphic. The way I am planning on using these characters is to have their value equal a string, then then during the transition do a CALL DELSPRITE(#), then CALL CHAR(char,nextsprite$), then CALL SPRITE(Next Sprite), etc. The same with characters that are moving horrizontally, have them transition from one graphic to the next until movement has stopped. I am doing it this way because with having 10-15 different sprites, all with variations, I'd prefer not to assign a character to each individual variation, would like to not run out, may need them. However, I'm not sure how much memory will be consumed.

 

Is this a fairly standard practice in BASIC? In C++ when working with MCUs I would simply assign a value and the system would call the information when needed, but it wouldn't burn up all the working memory when it wasn't being used, as it is essentially just a pointer. But with the TI, I don't know a lot about how it likes to handle code.

[Opry99er]

I've typically just assigned them to characters and used CALL PATTERN...did this in my Honeycomb Rapture game during the bee's "death spin".(available on Gameshelf).

 

Since you won't be doing that, you can (I think) just update the character(s) assigned to the SPRITE and it will adjust accordingly without deleting the SPRITE and re-calling it. I'm rusty, so forgive me if I'm recalling incorrectly.

[Opry99er]

This would be faster than deleting, re-assigning character data, and re-calling.

 

XB isn't known for it's wicked blazing speed... But if you're planning to COMPILE, it probably won't matter that much. Harry's compiler is sick...

[Tursi]

It's true, but you don't want to DELSPRITE in any case - that will sometimes cause the sprite to disappear from the screen, causing flicker. Just bravely change the shape while it's onscreen!

 

CALL CHAR is the slowest way to change the shape (even compiled)... if you have room in the character set to define all the shapes you need in advance, then just change the pattern as Opry99er suggests, that's the quickest way. (Otherwise, you'll feel the slowdown in XB, but CHAR should still be fast enough if compiled.)

 

Strings in XB are stored in VDP memory, IIRC, even if you have memory expansion. At least when running under the interpreter.

[+Lee Stewart]

... how exactly are string values stored? ...

 

...

Strings in XB are stored in VDP memory, IIRC, even if you have memory expansion. At least when running under the interpreter.

 

Yes, strings and variables in both TI Basic and TI Extended Basic (with/without memory expansion) are stored in two tables that grow down from the highest available VRAM. The first table contains a linked (?) list of the variable names. If a variable in the list is a number, it is followed by an 8-byte floating-point representation of the number. If the variable is a string, there is a pointer to the body of the string in the second list. The second list immediately follows the first. The strings are stored as packed strings, i.e., they each have a leading length byte, which means that strings cannot be longer than 255 characters. The string pointer in the first list does NOT point to the length byte, but one past it. With each new variable definition, the string-body table is moved down to make room. There’s probably more, but that is all I have figured out so far.

 

...lee

[+adamantyr]

Out of curiosity, and mostly because I hate to start another thread just to ask a question, how exactly are string values stored? Are they stored in RAM? The reason why I ask, is the sprites I am designing will have several variations. For example, turning 180 degrees from left to right would be broken up into the left facing charactor, a 45 degree, a 90 degree (screen facing), a 135 degree, and lastly a 180 degree graphic. The way I am planning on using these characters is to have their value equal a string, then then during the transition do a CALL DELSPRITE(#), then CALL CHAR(char,nextsprite$), then CALL SPRITE(Next Sprite), etc. The same with characters that are moving horrizontally, have them transition from one graphic to the next until movement has stopped. I am doing it this way because with having 10-15 different sprites, all with variations, I'd prefer not to assign a character to each individual variation, would like to not run out, may need them. However, I'm not sure how much memory will be consumed.

 

Is this a fairly standard practice in BASIC? In C++ when working with MCUs I would simply assign a value and the system would call the information when needed, but it wouldn't burn up all the working memory when it wasn't being used, as it is essentially just a pointer. But with the TI, I don't know a lot about how it likes to handle code.

You can change patterns with CHAR, but expect to see a little ripple refresh as its redefined. (Best practice, push all four character changes to the sprite in one CHAR statement) PATTERN is going to be faster because it only updates a single byte.

 

Animation frames in XB can be tough because of speed and availability issues. One thought... treat the patterns in more of a buffer fashion. Have only two exclusive patterns for one object, switch to one and redefine the other BEFORE you switch to it. That would let you avoid the ripple effect. I do this in assembly with screens, but the same technique is applicable anywhere.

 

Btw, really like the 16x16 Mega Man avatar.

[senior_falcon]

CALL CHAR is the slowest way to change the shape (even compiled)... if you have room in the character set to define all the shapes you need in advance, then just change the pattern as Opry99er suggests, that's the quickest way. (Otherwise, you'll feel the slowdown in XB, but CHAR should still be fast enough if compiled.)

Don't overlook XB256 which gives up 114 patterns for sprites and 256 additional patterns for characters. Programs written for XB256 can be compiled or not, depending on your requirements. This is part of the XB Game Developers Package.

[jdgabbard]

Btw, really like the 16x16 Mega Man avatar.

 

Thanks. It was inspired by the comments above.

 

Falcon, This is the first I've hear of XB256. Is this a cartridge similar to XB, or just an addon? Just for emulation on C99 or is it something that is available for the actual hardware?

 

I've been playing with CALL PATTERN. I think my algorithm is off, as I cant seem to get it do much of anything. I'm going to keep playing with it, and see what I can work up. At this point I'm just working on the physics. Scrolling maps is another issue that I'm going to eventually have to address, as I think that is going to use up a ton of memory. I have a NanoPEB, which if I'm not mistaken has the 32k memory. So that may not be so crucial. However, I'd like to no have to rely on that if possible. I will say this, BASIC might be more difficult to learn than C...

[senior_falcon]

Falcon, This is the first I've hear of XB256. Is this a cartridge similar to XB, or just an addon? Just for emulation on C99 or is it something that is available for the actual hardware?..

XB256 is a disk based program to add assembly subroutines to XB that greatly expand its capabilities. When you run the program it loads into lowmemory and is activated and runs quietly in the background. It will run on actual hardware, but requires XB, a disk drive and the 32K memory expansion. There is a thread on this site that you should be able to find if you search for XB256 with more information and some demos. Also search for "XB Game Developers Package". The compiler and XB256 are included in the same package to ensure compatibility between them.

Edited March 15, 2015 by senior_falcon

[+Lee Stewart]

... I have a NanoPEB, which if I'm not mistaken has the 32k memory. So that may not be so crucial. ...

 

It does, indeed.

 

...lee