TI99/4A and vector graphics

[whoami999ster]

I would like to implement something very similar to battlezone from atari for the TI99. In addition to having thought of using Tursi's smooth scrolling for the background .. I've no other idea ...  I was wondering if in any way you think it is possible to create with VDP something that can resemble vector graphics ... I have not found any thread on the topic and this already seems to be an answer, but does any of the TI99 guru's have any ideas on the this?
sorry for the stupid question and the bad english  ... but there has already been someone who has made it possible to make TI99 do things unthinkable ... so never put limits on providence ...

 

any documentation , links, exmple, raw code ... is welcome

 

Thanks and Ciao

Francesco

[Tuxon86]

42 minutes ago, whoami999ster said:

I would like to implement something very similar to battlezone from atari for the TI99. In addition to having thought of using Tursi's smooth scrolling for the background .. I've no other idea ...  I was wondering if in any way you think it is possible to create with VDP something that can resemble vector graphics ... I have not found any thread on the topic and this already seems to be an answer, but does any of the TI99 guru's have any ideas on the this?
sorry for the stupid question and the bad english  ... but there has already been someone who has made it possible to make TI99 do things unthinkable ... so never put limits on providence ...

 

any documentation , links, exmple, raw code ... is welcome

 

Thanks and Ciao

Francesco

I don't think it was really a vector based game on the 8bit computers. Wireframe doesn't mean it's vectoriel. They just drew the asset in wireframe and scrolled the playfield left and right 

[pixelpedant]

Seems like a design that's pretty impossible to implement on 9918A in anything like the original form.  Given you're trying to implement line-drawing, scrolling and object scaling, all in software.  

 

On the one hand, you'd want to minimise the quantity of the screen you're scrolling and scaling, to make to make that more achievable.

 

But on the other hand, if you're using sprites, you want to maximise the vertical extent of the screen on which they're placed, because the four sprite limit is going to come knocking immediately, if laid out in a way similar to the arcade game (where most objects are proximate to the horizon):

 

 

 

I'd say Buck Rogers: Planet of Zoom is probably your best TI-99 example of what this sort of game looks like, translated straightforwardly to a sprite-based approach.  Note how spread out objects are, vertically, to avoid that four sprite limit. 

 

 

And there's also Star Trek SOS, as far as games with sprite scaling go, and that was originally a vector game:

 

 

Any serious attempt here would probably involve

 

1) Limiting the height of "horizon" graphics.  Just make them a couple tiles high, so scrolling that is less costly.  Could even repeat a pattern, so it's just a couple four tile circular scrolls, or whatever. 

2) Using sprites for most objects. 

 

Which will probably look almost nothing like arcade Battlezone.  But it is what it is.  This is not a computer with support for vector graphics.  Solutions for implementing rich line drawing features exist.  Like The Missing Link and Logo.  But scrolling and scaling any wireframe objects you've drawn is another story. 

 

It can be fun to try to implement designs which are utterly inimical to the architecture.  But some realities are impossible to escape.  Unless you're Tursi or Rasmus.  In which case, they are merely a passing annoyance. 

 

But I suppose if one's fine with very low frame rates, anything is possible, here.  And you can just redraw the portion of the screen used with newly computed and generated tile-based wireframe graphics every single frame. 

 

 

 

[Asmusr]

1 hour ago, whoami999ster said:

any documentation , links, exmple, raw code ... is welcome

Which programming language are you planning to use?

Edited April 12, 2022 by Asmusr

[+arcadeshopper]

Battlezone was done on the colecovision no?

 

Also this is scrolling vector like graphic on stock expanded 4a

 

 

Sent from my Pixel 6 Pro using Tapatalk

 

 

 

 

[Asmusr]

Here are two demo cartridge images. "lines" is drawing using the bitmap pattern table only. You get monochrome graphics on a background for which you can choose the colors for each 8x1 pixels. "color-vector" is kind of the opposite, you draw to the color table only and can have 4x1 pixels of any color. Updating both patterns and colors would be too slow IMO. EDIT: requires 32K.

color-vector-8.bin lines-8.bin

Edited April 12, 2022 by Asmusr

[pixelpedant]

11 minutes ago, arcadeshopper said:

Battlezone was done on the colecovision no?

 

Nah, seems not.  And no MSX1 or SG-1000, but that makes sense, since this was an American Atari game. 

 

There was a VIC-20 version (also, C64 version).  And that offers a (pretty miserable) reflection of the pure tile graphics approach:

 

 

[Asmusr]

Regarding the speed, both demos are spending more time pushing data from 32K to VDP than actually drawing, so I think the "color-vector" demo could draw at least the same number of lines as "lines" without losing speed.

EDIT: "color-vector" is only pushing 4K while "lines" is pushing 6K. "color-vector" is using a double-buffer technique where the top 3rd of the screen is available for sprites only.

Edited April 12, 2022 by Asmusr

[+arcadeshopper]

https://images.app.goo.gl/pxhQnuqoCA6M1o8y7

Sent from my Pixel 6 Pro using Tapatalk

[HOME AUTOMATION]

Yes, I was thinking of LINES too...

 

[+dhe]

   Can't actually find a screen dump.

 

 

[Asmusr]

There are basically 3 ways of drawing vector graphics on the 9918A that I'm aware of (not considering sprites):

1. Draw directly to the VDP. You have to read every byte before you write, which is a lot slower than just writing to the VDP.
2. Write to a buffer in CPU RAM and transfer to VDP. You can write a pixel with single instruction, but the transfer of the full screen takes time.
3. Write to a buffer in CPU RAM and transfer only dirty rectangles to VDP. Great in theory but takes time to administrate in practice.

And about the drawing, you can pre-record graphics at different scales and shifts in ROM, which can speed up drawing a lot. 

Edited April 12, 2022 by Asmusr

[Asmusr]

There is also the option of writing each byte of 8 pixels without reading it first. For a game like Battlezone it might be OK to erase some background pixels. 

[pixelpedant]

15 minutes ago, dhe said:

   Can't actually find a screen dump.

 

 

 

Because it doesn't exist, as far as I can tell.  Not as a released product. 

 

This image seems to be a mock-up someone put on Etsy. 

 

Just another Atarisoft game that they planned to release for everything under the sun, then actually released for a subset of those.

 

Atari Museum lists it as "nicht erschienen"

 

The Etsy mockup seems to use the same design as the VIC-20 and C64 boxes:

 

 

[+arcadeshopper]

 
Because it doesn't exist, as far as I can tell.  Not as a released product. 
 
This image seems to be a mock-up someone put on Etsy. 
 
Just another Atarisoft game that they planned to release for everything under the sun, then actually released for a subset of those.
 
Atari Museum lists it as "nicht erschienen"
 
The Etsy mockup seems to use the same design as the VIC-20 and C64 boxes:
 

 

Can't trust the damn internet anymore. Grin

Sent from my Pixel 6 Pro using Tapatalk

[pixelpedant]

 

Can't really criticise anybody going around creating fake materials for unrelased games, given I am guilty of that myself:

 

 

Though at least in that case, we've got a playable prototype (or well, two of them). 

 

[+arcadeshopper]

 
Can't really criticise anybody going around creating fake materials for unrelased games, given I am guilty of that myself:
 

 
Though at least in that case, we've got a playable prototype (or well, two of them). 
 

At least that game exists

Sent from my Pixel 6 Pro using Tapatalk

[jstimson]

There was also Defender from Atarisoft on the TI.

 

Although Defender was not truly a vector game, it certainly had a lot of the look-and-feel of a vector game.

 

 

[apersson850]

Hmm, that's the game that gave me and my fellow 99'ers a condition we called "Defender thumb"...

[+Torrax]

Defender on the Colecovision featured smooth scrolling. The cartridge rom size was 24K compared to 8K on the TI.

I'm pretty impressed what Atarisoft achieved with the 8K on the TI version.

[+Vorticon]

I programmed Vortex for the 4K competition a few years back trying to give it a vector look and all the screen objects are line drawn. No sprites or defined characters. It's not very fast at rendering and can probably be optimized. 

[apersson850]

When I developed my turtle graphics unit for Pascal on the 99/4A, I wasn't aware of Bresenhams algorithm. My way is a bit more complex. It could benefit from optimizations.
Bresenham's can also be optimized, for example for vertical and horizontal lines. That's usually beneficiary when you have direct access to the video memory. Like drawing horizontal lines on the TI, where you can update 8 pixels at a time, if you make the routine a bit more complex.

Edited April 13, 2022 by apersson850

[whoami999ster]

18 hours ago, Asmusr said:

Which programming language are you planning to use?

I guess assembler no other option possible I think ... XB256 have smooth scrolling capabilities bat not for a wide background (I guess only background in loop) . Maybe after compile the result woud be fast enought ... but it's just a guess... 

I saw your lines demo and it's seems that line tracing could be feasible with an acceptable velocity. I know that raster is completely different from vector graph technology but battlezone was released for different 8-bit platform and I wonder that it would be be possible for TI99... 

My dream is to implement the game in assembler but but my knowledge is far from to be enough ... the initial idea came from your smooth scrolling examples/demos but another thing is to implement the game in assembler (... maybe in XB basic .. xb256 or TML which manage bitmap "natively"). 

I found this interesting link https://6502disassembly.com/va-battlezone/  (for me the listing is like hieroglyphs but maybe for you is simply ) ... battlezone was developed on 6502 processor ... so why not for TMS9900 ? 

    

   

[whoami999ster]

18 hours ago, pixelpedant said:

 

Nah, seems not.  And no MSX1 or SG-1000, but that makes sense, since this was an American Atari game. 

 

There was a VIC-20 version (also, C64 version).  And that offers a (pretty miserable) reflection of the pure tile graphics approach:

 

 

even VIC20 was able "to manage" battlezone! 

[whoami999ster]

17 hours ago, Asmusr said:

There are basically 3 ways of drawing vector graphics on the 9918A that I'm aware of (not considering sprites):

1. Draw directly to the VDP. You have to read every byte before you write, which is a lot slower than just writing to the VDP.
2. Write to a buffer in CPU RAM and transfer to VDP. You can write a pixel with single instruction, but the transfer of the full screen takes time.
3. Write to a buffer in CPU RAM and transfer only dirty rectangles to VDP. Great in theory but takes time to administrate in practice.

And about the drawing, you can pre-record graphics at different scales and shifts in ROM, which can speed up drawing a lot. 

any very simple example in assembler would be very appreciated for the 4 method you suggest  ... i.e tracing a rectangle or triangle