New game project...

[rocky007]

after many hesitations, i decided to start coding again on my old ti99..and i choosed my favorite game...a big one for a little TI.

For sure, it won't fit on a normal cartridge, it will request 1 floppydisk, with loading time between every stage.

Every stage have around 5 different screens, for a total of 28 if i remember well...

 

So, enough blabla, here it is the first screenshot... i only made graphics conversion for now, no sprite, no coding...just simple Xbasic with the the CHAR table.

 

If somebody interested in coding the main sprite routine, i take ! because honnestly, i'm not specialist of TI assembly... if someone want to join, he's welcome !

 

ah..i forgot....the game is...BRUCE LEEEEEEE

Edited May 15, 2010 by rocky007

[sometimes99er]

Looking good !

[Kurt_Woloch]

Hmmm... one thing I don't understand here is... what do you need so much memory for?

 

First, you seemingly already have proven that displaying one screen of this is possible under XB... so it needs less than 112 different characters. And I assume, from knowing the game, that actually many of the tiles that make up each screen repeat from screen to screen, so the whole set of tiles wouldn't have to be repeated for every screen. Maybe some of the colors change (most importantly the background color), but not the tiles themselves.

 

So first I'd try to fit the graphics for all the levels into 256 tiles. Then each level could be expressed by a series of 768 bytes. But you might need even less then this by compressing the levels somewhat. Maybe a RLE compression would be pretty efficient, but I can think of other ways to do this. Think HCHAR and VCHAR commands, but a bit expanded...

I could think of the following concepts that could be implemented with not too much effort...

 

1. horizontal line of same character (identical to HCHAR)

2. vertical line of same character (identiacl to VCHAR)

3. rectangle of same character (basically a combination of HCHAR and VCHAR, extending in both directions)

4.-6. horizontal line, vertical line and rectangle of different characters - these would work similar to HCHAR and VCHAR, but instead of repeating the same characters, these would fetch another character from a table for each character written on screen. Ideally, this sequence of characters wouldn't follow directly after the command, but instead the command itself would only give an index into a separate table giving the heights, widths and character sequences for all background objects that need to be drawn this way. That way, those objects could also appear in multiple screens in different positions without the need of defining them more than once.

 

Another trick would be to have the program split into two parts... the first one would load and then fill the VDP RAM with data, most importantly character and sprite definitions and sound lists (which normally run from VDP RAM!). Maybe even other data could be written to VDP RAM that gets read from the main part. Then the main part would load, which takes up another 32 K in memory, and would stay in memory while the game is running without the need of loading in different parts.

 

This, of course, is assuming this is going to be an entirely assembly project without an XB part to it.

[+retroclouds]

hi rocky007,

 

wow, Bruce Lee on the TI-99/4A that will be a blast

Looking forward seeing how this further develops.

 

Don't forget that Jons' cartridge boards can sport up to 64K (8 x 8K banks).

So with compression I think you should be able to stuff the screens in.

 

Depending if you want the game to require 32K memory you could decompress to RAM,

but I think this kind of game should be possible also with only 256 bytes scratch-pad memory

run on a bare console (256 bytes memory)

[rocky007]

Thanks Kurt_Woloch and Retroclouds for the idea and comments.

 

There are much more then 256 tiles. I didn't counted precisely, but think 1024 at least.

But the biggest problem is the sprite's graphics. It doesnt look like but Bruce Lee have 28 moves,

28 for green sumo, and 18 for black ninja. For some position of BruceLee and Green Sumo, i need 29*18 sprite, multiplicate by 2, for the two colors. Just for the "foot strike" move, i already need 32 tiles ! Hopefully, the half can be mirrored, but it still very hard to all sprites into only 128 tiles, in the best case i can use 128 others for the level graphics ! I have to make some test to redesign the sprite in economic mode !

 

Now, i have another problem : if i remember well it's impossible the put more than 4 sprites on same line.

For some position of BruceLee and Green Sumo, in the maximum condition, i need 4 sprites for Brucelee and 4 for green sumo, 1 for ninja, so in total 9 sprites on same line. Again the only way for me is to sacrify the original size and colors.

 

Finally, don't forget that i can't use straightly the original tiles. I made a little program that help me to convert tiles by tiles from original pictures. Why ? The original tiles are in 4 colors on 320 * 200 screen ! So to be close to original have a play with the color banks. Sometime, one original tiles is splitted into 2 to keep the right color. For the level itself, i don't worry, it can be compressed and i can also use special routine ( X,y,c box ), i can define all levels in less than 5000 bytes.

 

About memory, i don't worry, like Retrocloud said, there are many way to solve this. Just need to think about the sprite problem & avalaible tiles.

Edited May 15, 2010 by rocky007

[+retroclouds]

You could try to make Bruce Lee and Ninja a combination of sprites and tiles

[rocky007]

You could try to make Bruce Lee and Ninja a combination of sprites and tiles

 

 

in fact i'm thinking to other way :

 

1) the original game is 320*200, but possible to fit in 160*100 because double-sized pixel.

if i reduce the size of screen, i will economy many avalaible tiles...just...it's not really pleasant to play

 

2) i'm thinking of using true bitmap mode

[Kurt_Woloch]

Well, about the sprites per scanline thing...

 

The original version of Bruce Lee is for the Atari 800, and it seems to entirely use the player graphics for the player and his enemies (not the static moving things, those seem to be part of the background). The player graphics allows for 5 objects on screen, or 4 players and 4 missiles, but in this case it seems like they did the "display 5th player instead of missiles" thing. Both the Green Sumo and Bruce Lee have 2 colors each, and the black ninja is 1 color.

 

Then I noticed that for both the Green Sumo and Bruce Lee, actually only 3 sprites would be needed most of the time because their bottom part is monochrome (green on Green Sumo and black on Bruce Lee). There is one exception, however... both Green Sumo and Bruce Lee need a fourth sprite when they are performing the foot strike move. But this only applies to their lower part where they are monochrome anyway... or at least they are monochrome in their lower part while performing this move.

 

So, all in all, I think 5 is the maximum number of sprites that could possibly appear on one scanline. I'd arrange the sprites so that this has the lowest possible impact... so that the first sprite to disappear if more than four are on one scanline would be Green Sumo's black body parts, which are relatively sparse, then Bruce Lee's upper flesh parts. When performing the foot strike move, I'd first remove the rear part of the character performing this move if necessary (because the front part is the kicking one).

 

By the way, when programming in assembly, the sprites and the background do not have to share the same graphics tiles... they only do this in XBasic to save memory for the actual code. But in assembly, the sprite pattern table can be on a different address in VDP RAM than the main pattern table... so you have 256 tiles for the background and another 256 for the sprites.

[+retroclouds]

Well, about the sprites per scanline thing...

 

The original version of Bruce Lee is for the Atari 800, and it seems to entirely use the player graphics for the player and his enemies (not the static moving things, those seem to be part of the background). The player graphics allows for 5 objects on screen, or 4 players and 4 missiles, but in this case it seems like they did the "display 5th player instead of missiles" thing. Both the Green Sumo and Bruce Lee have 2 colors each, and the black ninja is 1 color.

 

Then I noticed that for both the Green Sumo and Bruce Lee, actually only 3 sprites would be needed most of the time because their bottom part is monochrome (green on Green Sumo and black on Bruce Lee). There is one exception, however... both Green Sumo and Bruce Lee need a fourth sprite when they are performing the foot strike move. But this only applies to their lower part where they are monochrome anyway... or at least they are monochrome in their lower part while performing this move.

 

So, all in all, I think 5 is the maximum number of sprites that could possibly appear on one scanline. I'd arrange the sprites so that this has the lowest possible impact... so that the first sprite to disappear if more than four are on one scanline would be Green Sumo's black body parts, which are relatively sparse, then Bruce Lee's upper flesh parts. When performing the foot strike move, I'd first remove the rear part of the character performing this move if necessary (because the front part is the kicking one).

 

By the way, when programming in assembly, the sprites and the background do not have to share the same graphics tiles... they only do this in XBasic to save memory for the actual code. But in assembly, the sprite pattern table can be on a different address in VDP RAM than the main pattern table... so you have 256 tiles for the background and another 256 for the sprites.

 

EDIT: If you have 5 sprites in a row, you could also rotate the sprite entries in the sprite attribute table. That way you will get some flicker, but if done in a smart way it should be quite acceptable.

Edited May 15, 2010 by retroclouds

[Opry99er]

Lookin slick!!! Assembly, eh? Well---you are a brave man taking on assembly. Matthew, Karsten, Adamantyr, Mark Wills, Vorticon.... All excellent resources for assembly knowledge. I'm learning myself.

[Opry99er]

And the guy who brought us to Atariage--- Filip Van Vooren. Pitfall.... Masterpiece, man--- truly

[rocky007]

Well, about the sprites per scanline thing...

 

The original version of Bruce Lee is for the Atari 800, and it seems to entirely use the player graphics for the player and his enemies (not the static moving things, those seem to be part of the background). The player graphics allows for 5 objects on screen, or 4 players and 4 missiles, but in this case it seems like they did the "display 5th player instead of missiles" thing. Both the Green Sumo and Bruce Lee have 2 colors each, and the black ninja is 1 color.

 

Then I noticed that for both the Green Sumo and Bruce Lee, actually only 3 sprites would be needed most of the time because their bottom part is monochrome (green on Green Sumo and black on Bruce Lee). There is one exception, however... both Green Sumo and Bruce Lee need a fourth sprite when they are performing the foot strike move. But this only applies to their lower part where they are monochrome anyway... or at least they are monochrome in their lower part while performing this move.

 

So, all in all, I think 5 is the maximum number of sprites that could possibly appear on one scanline. I'd arrange the sprites so that this has the lowest possible impact... so that the first sprite to disappear if more than four are on one scanline would be Green Sumo's black body parts, which are relatively sparse, then Bruce Lee's upper flesh parts. When performing the foot strike move, I'd first remove the rear part of the character performing this move if necessary (because the front part is the kicking one).

 

By the way, when programming in assembly, the sprites and the background do not have to share the same graphics tiles... they only do this in XBasic to save memory for the actual code. But in assembly, the sprite pattern table can be on a different address in VDP RAM than the main pattern table... so you have 256 tiles for the background and another 256 for the sprites.

 

yes, i'm working right now on sprite animation, and i will take 2x3 tiles for every move. It won't be exactly like original, i need to stretch a little, but honnestly i think it's acceptable. Like you explained perfectly, i will manage monochrome part in the best way to avoid flickering.

 

Here is it the first preview of sprite conversion, of course, it's in XB, so very slow

 

[rocky007]

 

 

EDIT: If you have 5 sprites in a row, you could also rotate the sprite entries in the sprite attribute table. That way you will get some flicker, but if done in a smart way it should be quite acceptable.

 

 

So, in assembly, is it maximum 5 or 4 sprites on same row ? (without flickering)

[rocky007]

mmmh... i'm reading and reading about these **** sprites...

 

someone could explain me how games like Qbert or Jungle Hunt can handle so many colors in sprites, and without flickering ?

[sometimes99er]

mmmh... i'm reading and reading about these **** sprites...

 

someone could explain me how games like Qbert or Jungle Hunt can handle so many colors in sprites, and without flickering ?

The TI-99/4A will display a maximum of 4 sprites horizontally. And a maximum of 32 sprites per screen. An emulator may show more.

 

Main character in Jungle Hunt has sprites stacked vertically. One or two sprites are used horizontally ...

 

 

Screen characters can be used to simulate sprites or add extra color to sprites. Pac-Man (Atarisoft) has the eyes of the ghosts made up in the background characters. Try it out in Classic99 and then disable sprites (video menu). You'll see eyes moving around on their own.

 

 

Edited May 16, 2010 by sometimes99er

[rocky007]

mmmh... i'm reading and reading about these **** sprites...

 

someone could explain me how games like Qbert or Jungle Hunt can handle so many colors in sprites, and without flickering ?

The TI-99/4A will display a maximum of 4 sprites horizontally. And a maximum of 32 sprites per screen. An emulator may show more.

 

Main character in Jungle Hunt has sprites stacked vertically. One or two sprites are used horizontally ...

 

 

Screen characters can be used to simulate sprites or add extra color to sprites. Pac-Man (Atarisoft) has the eyes of the ghosts made up in the background characters. Try it out in Classic99 and then disable sprites (video menu). You'll see eyes moving around on their own.

 

 

 

It's very interesting, i will try Qbert and Jungle Hunt under classic99 and disable the sprite to check how they did...

 

Because on Jungle Hunt, on last stage, you have the 2 cannibals + hero on the same line, even sprite decomposed like you showed me, it's not possible in sprite.

 

Same in Qbert, the balls have 2 colors, the hero have 3 colors, and snake only one. On pictures, you can see on same row 1 ball, 1 snake and the hero.

 

I'm investigatinf

 

 

UPADTE

 

Qbert flickering (( on youtube it wasn't visible, but the eyes sometimes disappears...

...now checking with Jungle Jung

Edited May 16, 2010 by rocky007

[Opry99er]

Cool stuff here guys... Interesting thread--- I'm reading intently.

[Tursi]

Looks like good progress! The questions were sort of unanswered - it's always 4 sprites on a line. This is a hardware limitation so it doesn't matter what language you code it in.

 

Besides the clever tricks Sometimes already mentioned, sometimes you have to flicker. There are two ways to do this.

 

One is to order your sprites so that the ones that disappear (higher number) won't really impact the game play. They vanish, but they were just extra colors.

 

The other is an actual flicker routine. The purpose of a flicker routine is to change the sprite numbers every frame so that if a sprite disappears, it will only be gone for one frame. There are a lot of ways to do this, but the approach I prefer is very simple and I haven't seen better results from any other. You can only get good flicker results from assembly or another compiled language, Extended BASIC won't be fast enough and can't detect the frame sync.

 

The first step is to determine how many sprites you need. The fewer sprites that flicker, the faster the flicker will be and the better it will look. For instance, let's say you want 16 sprites onscreen in your game.

 

The second step is to arrange your sprites. Assume 0-15 for now. Space out your multi-colored sprites so the different colors are 4 or more sprites apart - this helps to ensure some part of the character is always onscreen.

 

Finally, define your sprite table in CPU RAM - this is a mirror of the VDP sprite table. Do all your sprite updates there (this gives you a small speed boost, too, which is nice, and even a full 32-sprite table is only 128 bytes). Have an interrupt routine that runs during vertical blank. This interrupt routine will copy the sprite table to VDP RAM, starting at a different offset each frame. This way, your program still sees the sprites as 0-15, but the VDP will see different numbers each time, so different sprites are the 'highest' number and disappear on different frames. Persistence of vision does the rest, and you see the sprite as just 'flickering'.

 

This routine is also nice because you don't have to care whether any sprites are on the same line and need flickering or not - because you rotate the table every frame, the flickering just happens automagically when it's needed.

 

For example, let's say there are 8 sprites, and we have them all on one line. I will say they are the first 8 letters of the alphabet. When we first run the program, and we copy them to VDP, the VDP Sprite Table will see them like so:

 

A B C D E F G H

 

Because we can only have 4 sprites on a line, though, on screen we will see this:

 

A B C D

 

The next frame, we increment our start pointer by 4. We copy from there to the end of the table, then, knowing we aren't done, we copy from the beginning of the table to the start pointer. In essence, the CPU sprite table becomes a ring buffer. We increment by 4, because that's how many sprites are allowed on a line. So this time, the VDP Sprite table looks like this:

 

E F G H A B C D

 

but the actual sprite information has not changed, only the order in the table. Because of this, on screen we will see this:

 

E F G H

 

When the next frame comes, we again increment by 4. We notice we are off the end of the table (which was 8 entries long), and reset to 0, which will give us the first case again. This makes the sprites flicker 4 at a time (which is the worst case), and since there are only two frames before it repeats, the worst case is 1 in 2 frames.

 

If you had 16 sprites, then it would take 4 frames to repeat, so the worst case is 1 in 4 frames, which is still tolerable. If you use all 32 sprites, the worst case becomes 1 in 8 frames, which is not very tolerable, but since it's usually not too frequent, it's okay.

 

The pseudocode would look like this. I'll do it in Extended BASIC, and you can actually run it. You'll see how it works then, but remember to actually "flicker" you have to run it every frame, at that speed it looks good. (Even as is, you will probably want to speed up the emulator - with Classic99 use CPU Overdrive ). With the XB copy, it's slow enough that you can see the updates as they happen - this causes characters that shouldn't flicker to do so slightly as they are moved, and sometimes the wrong character is briefly visible. In assembly you do this during the vertical blank, so it's never visible.

 

This code lets you move the 'A' with joystick 1, so you can see how you have to update the mirrored table and not the VDP one, but that it still works. You can also see how that affects the actual flicker, but it is very slow. Run it at normal speed first, then kick in CPU Overdrive (or in MESS, whatever the speed up mode there is), and you can get a better visualization of the flicker itself.

 

100 REM SPRITE FLICKER SAMPLE
110 REM SHOWS (SLOWLY!) A FLICKER
120 REM OF 12 SPRITES ON ONE LINE
130 REM MOVE THE 'A' WITH JOYSTICK 1
140 REM
150 REM THIS IS THE SPRITE TABLE
160 REM (ROW, COLUMN, CHAR, COLOR)
170 DIM ROW(12),COL(12),CH(12),HUE(12)
180 INDEX=1 :: REM WHICH SPRITE IS COPIED FIRST
190 REM
200 REM SET UP THE SPRITES
210 FOR I=1 TO 12
220 ROW(I)=100 :: COL(I)=I*12 :: CH(I)=64+I :: HUE(I)=1+I
230 NEXT I
240 CALL CLEAR :: CALL SCREEN(15)
250 REM
260 REM MAIN LOOP
270 GOSUB 350 :: REM COPY SPRITE TABLE TO VDP
280 CALL JOYST(1,X,Y):: REM READ JOYSTICK
290 REM NOTE WE HAVE TO UPDATE THE MIRROR, NOT THE
300 REM REAL TABLE, SO WE CAN'T USE AUTO-MOTION
310 ROW(1)=(ROW(1)-Y)AND 255 :: REM THE AND HELPS IT WRAP AROUND
320 COL(1)=(COL(1)+X)AND 255 :: REM THE AND HELPS IT WRAP AROUND
330 GOTO 270
340 REM
350 REM COPY SPRITE TABLE
360 REM YOU WOULD NORMALLY DO THIS IN ASSEMBLY
370 REM IN A SINGLE COPY OF A MIRRORED SPRITE
380 REM TABLE, BUT HERE WE HAVE TO DO IT
390 REM THE SLOW WAY. AT LEAST YOU CAN SEE
400 REM WHAT IT DOES!
410 REM COPY FROM INDEX
420 VDPINDEX=1
430 FOR I=INDEX TO 12
440 CALL SPRITE(#VDPINDEX,CH(I),HUE(I),ROW(I),COL(I))
450 VDPINDEX=VDPINDEX+1
460 NEXT I
470 REM COPY FROM START
480 FOR I=1 TO INDEX-1
490 CALL SPRITE(#VDPINDEX,CH(I),HUE(I),ROW(I),COL(I))
500 VDPINDEX=VDPINDEX+1
510 NEXT I
520 INDEX=INDEX+4 :: IF INDEX>12 THEN INDEX=1
530 RETURN

[sometimes99er]

Edited June 8, 2012 by sometimes99er

[rocky007]

Thanks for the very detailled explaination tursi !

It's very interesting and need to be tryed. I will try different tricks and i'll decide wich one looks better in this case.

[Tursi]

The questions were sort of unanswered - it's always 4 sprites on a line. Besides the clever tricks Sometimes already mentioned, sometimes you have to flicker.

Excellent humour mate. Where do you get it from ? The answers are sort of wrong though. It's not always 4 sprites on a line. And you don't have to flicker.

 

Ah, so this is the post you were talking about. I am trying very hard not to take offense given the other things you have said privately, since it is in the past, but I would like to see an explanation of that statement.

 

I'm sorry if I'm stepping on your toes. I thought our posts were good complements to each other.

[sometimes99er]

The questions were sort of unanswered - it's always 4 sprites on a line. Besides the clever tricks Sometimes already mentioned, sometimes you have to flicker.

Excellent humour mate. Where do you get it from ? The answers are sort of wrong though. It's not always 4 sprites on a line. And you don't have to flicker.

 

Ah, so this is the post you were talking about. I am trying very hard not to take offense given the other things you have said privately, since it is in the past, but I would like to see an explanation of that statement.

 

I'm sorry if I'm stepping on your toes. I thought our posts were good complements to each other.

Thanks for trying not to take offense. I don't think I can be clear the way you want it. Sorry.

[Tursi]

Then I'll do it myself.

 

When I said "it's always four sprites on a line", I meant that the MAXIMUM number of sprites on a scanline, in any mode supporting sprites, from any language, on the TMS9918A VDP, is four. You can obviously display fewer. You can not display more in a single frame. IF you have to, that is where flicker comes in useful, and I've already gone into detail on how that works.

 

It's important to remember that it's not visible parts of the sprite that count (as is true on machines like the 2600)... the VDP looks at the sprite positions and makes its decisions about which sprites to draw before looking at the patterns. So the entire square sprite counts.

 

Flicker is never mandatory. Again, I considered this obvious, but in case of confusion I will explicitly state it. Flicker is just a technique to allow the illusion of more sprites than are normally permitted by the hardware. (It can also be used for special effects).

 

Apparently my speaking too generically caused some friction here, I apologize as that was not my intent.

 

Back to the game discussion.

[Kurt_Woloch]

Some comments to the stretching of sprites...

 

I've done some calculations regarding to the pixel clock frequency of the TI-99, the Atari 8-bit computers and the Commodore 64 in order to determine the correct stretching ratio so that pictures would keep the same aspect ratio from platform to platform.

 

The Atari 8-bit has a pixel duration of 140 nS; pixels of players are normally 280 nS wide. The pixel clock of the TI-99 is about 187 nS. On all systems, the pixel clock is somewhat derived from the NTSC color burst of 3.579545 MHz. On the Atari 8-bit, 1 player pixel or 2 hi-res pixels occur during one color burst period. On the TI-99, 1.5 pixels get drawn during that period, and on the Commodore 64, 9 multicolor or 18 hi-res pixels get drawn during 8 periods.

 

Thus... a player on the Atari 8-bit which is 8 pixels wide would correspond to 12 pixels on the TI-99/4A. Similarly, 4 normal width character positions on the Atari 8-bit would correspond to 3 character positions on the TI-99.

 

On the C-64, normal-size sprites are 3 characters (24 pixels) wide, and this actually corresponds exactly to the 16-pixel sprites of the TI-99/4A which should appear the same width on screen. Correspondingly, 3 character positions on the C-64 should correspond to 2 character positions on the TI-99.

[sometimes99er]

How about ... The C64 and Atari has 40 columns. The TI has 32 columns. Then 40 pixels would equal 32 pixels, or in other words 5 characters wide is 4 characters on the TI. A C64 sprite would be ... eh, 3 characters wide * 8 pixels / 5 characters * 4 characters = 19.2 pixels. Hmmm ...