OT: Excellent intro to early computer graphics

[freewheel]

This is an EXCELLENT introduction to how early 80s computers and game systems handled graphics in a memory-constrained environment. While the exact details differ, this first video is very similar to how we handle drawing to the screen on the Intellivision. It might help clear up some of these concepts for people. When he zooms in on the graphics - that's something that every Inty programmer has to deal with when we try to make detailed screens.

 

Translations: What he calls a "cell", we call a "tile" or "card". And a card can only be 2 colors; there is no fancy 4 color mode like on the Commodore. Also "sprite" equals "MOB", although IntyBASIC also uses the SPRITE command.

 

 

Not sure if this is worthy of the main forum or not, but I know some here might get a kick out of this. It's very well done.

[pimpmaul69]

I enjoyed that. Now i need to find part two

[intvnut]

Fun Fact: The term sprite was apparently coined by someone at Texas Instruments for their TMS9918 VDP. I have this detail from Karl Guttag, who was on the TMS9918A VDP design team (and inventor of its Graphics II pseudo-bitmap mode). Karl is the guy who hired me into TI.

 

I consciously chose the term MOB in my documentation for the Intellivision to roughly match the STIC summary from the BSRs (see "moving objects" and "cards" here) and the Commodore 64 documentation I had read growing up. (Something along these lines.) Given that the STIC predates the VDP, if ever so slightly, it seemed like a reasonable way to be at least somewhat authentic. The STIC data sheet just refers to "objects."

 

I don't remember what Carl called them in his reverse engineering docs; however, a quick look at William Moeller's De Re Intellivision from 1997 refers to "moving objects" just as the BSR's text linked above.

[freewheel]

I consciously chose the term MOB in my documentation for the Intellivision to roughly match the STIC summary from the BSRs (see "moving objects" and "cards" here) and the Commodore 64 documentation I had read growing up.

 

MOB seems Inty-authentic, but are you sure the Commodore scene used the term? I always read "sprite" growing up - and I learned from C= programming manuals to boot.

[+DZ-Jay]

 

MOB seems Inty-authentic, but are you sure the Commodore scene used the term? I always read "sprite" growing up - and I learned from C= programming manuals to boot.

 

I seem to remember MOB and Sprite being used interchangeably in the C=64 Programmer's Guide.

 

My own personal use of the terms, one that I had picked up over the years and assumed was standard, represents the logical cognitive level of its use:

a MOB is a Movable Object Block, a "physical" memory object in hardware, which when displayed, moves independently of the rest of the screen background; while a Sprite is a logical abstraction of a moving element on the screen.

 

Therefore, a Sprite is implemented using one or more hardware MOBs. Sprites can be animated, and can be in various game states; MOBs point to specific graphical pictures in memory, and can be on, off, visible, or invisible.

 

-dZ.

[intvnut]

 

MOB seems Inty-authentic, but are you sure the Commodore scene used the term? I always read "sprite" growing up - and I learned from C= programming manuals to boot.

 

I first picked up the term from the Simon's BASIC manual on a friend's C64. C64's default BASIC didn't natively support sprites/MOBs/etc. You had to POKE everything. So most of the messing-around that I did was through Simon's BASIC and/or some graphics designer tools.

 

I didn't own a C64 back in the day, so most of my C64 knowledge came from third party books, magazines, and playing with Simon's BASIC. But I definitely learned the term MOB in a C64 context in the 1980s.

 

 

 

I seem to remember MOB and Sprite being used interchangeably in the C=64 Programmer's Guide.

 

My own personal use of the terms, one that I had picked up over the years and assumed was standard, represents the logical cognitive level of its use:

a MOB is a Movable Object Block, a "physical" memory object in hardware, which when displayed, moves independently of the rest of the screen background; while a Sprite is a logical abstraction of a moving element on the screen.

 

Therefore, a Sprite is implemented using one or more hardware MOBs. Sprites can be animated, and can be in various game states; MOBs point to specific graphical pictures in memory, and can be on, off, visible, or invisible.

 

In fact, that's exactly the split I used in Space Patrol: Sprites are the individual moving objects I track in the game world. They're displayed by mapping onto (or multiplexing onto) the hardware MOBs.

 

On the TMS9918 VDP, though, they use sprite to refer to one of the 32 moving objects you can display onscreen at a time. The VDP has a limit of 4 sprites on a line, as it actually has only 4 shift registers for holding sprite data. Later VDP derivatives (such as the chips used in the Sega Master System and Sega Genesis—both register compatible with the 9918 VDP!) keep this architecture, increasing the sprites-on-a-line and total sprite count. In the VDP world, sprite always referred to the hardware-supported construct.

[carlsson]

Actually Simons' Basic on the C64 uses the MOB keyword:

https://en.wikipedia.org/wiki/Simons%27_BASIC#Sprite_.28MOB.29_handling_keywords

 

I'm not sure how many else in the Commodore world used this naming, but clearly MOB is three characters less than SPRITE so more (ROM) memory efficient.

 

In the Swedish translation of "Computer Awareness Programs for Adults" by Texas Instruments 1983, they refer to sprites as "sagoväsen" which literally means fairy tale creatures, and I think is their way to translate the word "sprite" into something that readers would grasp. However I can't say that I've been living by the assumption a number of fairy tale creatures have flown across the screen for 30+ years.

[freewheel]

Huh. I guess I did all of my learnings from stuff like this:

 

http://www.commodore.ca/manuals/c64_users_guide/c64-users_guide-06-sprite_graphics.pdf

 

In fact I had a fairly strong flashback moment when I found that just now. My very first sprite was indeed that balloon - I might have tried something on the Vic-20 but I have no specific recollection now. Never had any fancy alternate BASICs or RAM extenders or any of the other expensive add-on carts. We had to suffice with everything on datasette/floppy

 

I've also thought a lot about DZ's MOB vs SPRITE comment. I think IntyBASIC could benefit from this sort of higher-level construct, but unfortunately the language definition is already set. Maybe we can have a "SPRGRP" or something that defines multiple SPRITES so you can control them all together.

[intvnut]

Huh. I guess I did all of my learnings from stuff like this:

 

http://www.commodore.ca/manuals/c64_users_guide/c64-users_guide-06-sprite_graphics.pdf

 

In fact I had a fairly strong flashback moment when I found that just now. My very first sprite was indeed that balloon - I might have tried something on the Vic-20 but I have no specific recollection now. Never had any fancy alternate BASICs or RAM extenders or any of the other expensive add-on carts. We had to suffice with everything on datasette/floppy

 

You know what, that looks familiar! I don't think I ever really wrapped my head around the required POKEs, etc. 30 years ago, though. I do remember typing in programs from the book, and I do recognize the C64 balloon.

 

 

I've also thought a lot about DZ's MOB vs SPRITE comment. I think IntyBASIC could benefit from this sort of higher-level construct, but unfortunately the language definition is already set. Maybe we can have a "SPRGRP" or something that defines multiple SPRITES so you can control them all together.

 

The EXEC has a construct like this. (It's also exposed in ECS BASIC as CALL LINK.) You set up the objects you want to group together, and then you "link" them. IIRC, anything you do to the first object in the group applies in a relative fashion to the LINKed objects. So, if you're overlaying two objects to make a multi-color object, moving the first object moves both together. Or, if you're building a really big object (like the Recognizer in TRON Deadly Discs), moving the first object moves the entire large object.

 

 

Actually Simons' Basic on the C64 uses the MOB keyword:

https://en.wikipedia.org/wiki/Simons%27_BASIC#Sprite_.28MOB.29_handling_keywords

 

I'm not sure how many else in the Commodore world used this naming, but clearly MOB is three characters less than SPRITE so more (ROM) memory efficient.

 

*shrug* For me, it was a keyword I first encountered on the C64, and it is shorter to type.

 

 

In the Swedish translation of "Computer Awareness Programs for Adults" by Texas Instruments 1983, they refer to sprites as "sagoväsen" which literally means fairy tale creatures, and I think is their way to translate the word "sprite" into something that readers would grasp. However I can't say that I've been living by the assumption a number of fairy tale creatures have flown across the screen for 30+ years.

 

I almost wonder if just using 'sprite' as an opaque loan-word might have been better here. Some words just don't need to be translated. So far as I know, there's no English translation for lutfisk, for example.

[carlsson]

Yes, most other books, magazines etc would preserve "sprite" as a loan word. I suppose the translator working for TI Sweden could've went for translating sprite as fairy into "fe", but then you get associations of a creature fulfilling your wishes with a magic wand. In many cases, you might find that a movable object fulfills at least your wish of a smooth moving object that won't cause colour clashes with the background/character graphics, so in that respect it could work to think of a sprite as a fairy...

 

Btw, the C64 balloon has a story on its own regarding an odd pixel creep that occurred some time between translations of the manual, but that is a story for another thread.