video games

[Deleted User]

hi , any body have any code for some simple video games for the propeller .

Thanks,
·Brian

ciw1973

Your best bet would be to wait for the Hydra.

Surely it can't be far off now?

LoopyByteloose

I really want a workable version of Asteroids.
Does anyone have a status on that particular game?

Pong and Pac Man make me feel like a pre-teen.

I need Hyper-space and negative gravity.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"If you want more fiber, eat the package.· Not enough?· Eat the manual."········

···················· Tropical regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan

[Deleted User]

That's what i'm looking for , I thought the propeller would be perfect for them games

Thank's brian

Ym2413a

It is a great chip for games.
A lot of people are working on game related projects and firmware as we speak.
I've been writing a sound engine designed for games in mind that will release soon after the Hydra releases.

Truckwiz, your best bet is to play around and see what you can come up with, because it's only a matter of short time before the Propeller retro gaming scene opens up and takes shape. We'll have standardized hardware to work with and firmware that will be openly shared.

AndreL

The HYDRA as mentioned comes with a ton of games and demos all with complete source. Both SPIN and ASM stuff, basic to bleeding edge ASM 3D stuff. Even asteroids that you want, happens to be the demo that is pre-loaded on the system. But, its called "Parallaxaroids" [noparse]:)[/noparse]

The HYDRA release is getting VERY close, an announcement will be made soon once they units are all ready to go.

Everyone will have years of source code to figure out, it will keep everyone very busy [noparse]:)[/noparse]

Andre'

[Deleted User]

Hi,

·I'm not using it for a game , i'm just tring to figure out some of the graphics option's , take this program, I can't tell·what line changes color for text & what one changes the screen color , they seem to have a affect on each other ( I marked the 2 lines)

Thank's· Brian



con
· _clkmode = xtal1 + pll16x
· _xinfreq = 5_000_000
· newline = 13
·

obj
· videodisplay: "TV_Terminal"
· kb··· :······ "Keyboard"

pub start

·videodisplay.start(12)
·setscreen
·kb.start(26,27)
·waitcnt (50_000_000 + cnt)

·if kb.present
· videodisplay.str(string( "······BOB & SAM'S COMPUTER!"))
· videodisplay.out(13)
· videodisplay.out(13)
· videodisplay.str(string("············ START TYPING !!···· "))
· videodisplay.out(13)
· videodisplay.out(13)
· repeat
··· videodisplay.out(kb.getkey)

·else
··· videodisplay.str(string(" ERROR : KEYBOARD NOT CONNECTED" ))
pri setscreen
· videodisplay.out(3)·· THIS LINE
· videodisplay.out(5)···& THIS LINE



Post Edited (truckwiz) : 10/21/2006 12:45:42 AM GMT

AndreL

You need to look in the videodisplay object's source which is a instantiation of the tv terminal, those ascii codes select palettes if I recall (i didn't write that one), and those palettes are pre-defined in the object at the end. So, if you look at the code, you will see that there are some palettes at the end and certain control codes select the palettes which then result in text with a specific foreground and background color. When the hydra does come out the book that comes with goes into bloody detail about the parallax reference drivers and graphics and tv drivers as well as the advanced sprite and tile engine drivers I developed, so you will be able to use all these functions better. In the meantime, you might want to look at the generic graphics demo chip wrote that puts lines, starts, etc. on the screen for more insight into how color works. Basically, each tile has a palette associated with it via an index, this palette is used for both bitmapped and text graphics. So you first have to look at that to see how the palettes are arranged (an array of longs) and then the format of each palette entry is 4 bytes, where each byte represents colors 3,2,1,0 from high to low, and each color is in chroma | luma format. There's a lot of indirection, but once you have a template going then its easy. Which of course the hydra book and source has many of, that is demo templates that set things up for you, so you can focus on programming rather than set up.

Andre'

[Deleted User]

thank's andre'
is there away to take this 4 lines of code & make 2

brian

if kb.present
videodisplay.str(string( " BOB & SAM'S COMPUTER!"))
videodisplay.out(13)
videodisplay.out(13)

AndreL

I would have to look at the tv terminal, but you might be able to just add the 13's in the string itself then print the string, there is no need to make all these calls. But, you have to make sure the str sub-function can parse the 13's as well, or if that's just part of the out sub-function. Just crack open the tv_terminal and take a look.

Andre'

[Deleted User]

13= newline
I tried:

videodisplay.str(string( " DA DA DA"13,13))

i get a error

thank's

AndreL

This isn't C [noparse]:)[/noparse] You have to BUILD a string up with those characters by accessing the string data or making a string for example:

videodisplay.str(my_string)

DAT

my_string byte "hello world", 13, 13


But, like I said, we haven't ascertained if the str function can handle the special codes or only the out function, you need to look at the function itself to figure that out.

Andre'

[Deleted User]

WoW , I love this chip , but nothing like starting from a dead stop , is there any more documentation out there as of right now , besides the book that comes with it. right now I'm just looking at other programs to see what effects what , kinda trial by fire.

Thanks

Brian

Post Edited (truckwiz) : 10/21/2006 1:35:39 AM GMT

AndreL

There is the propeller manual and there are dozens of demos on this board in the forums for begineers. But, the "book" on spin and propeller programming is coming soon with the hydra and sold seperately as "Game Programming for the Propeller Powered Hydra", so until then you have to wait a bit. But, its like 900 pages, so it will keep you busy when you get it.

Andre'

Dennis Ferron

I half-finished a clone of QBASIC Nibbles but have been too busy to finish it, with college (full time) and working 3 jobs to make ends meet. I get maybe 3-4 hours of sleep a night...


Eventually I would like to port all of my favorite games - QBASIC Gorillas, Commander Keen, Elite, Oregon Trail...

I have a vector-graphics 3-d space game I wrote in C++ and assembly for CGA graphics; that game would work well on the Propeller, too. It seems like a million years since I wrote the game and none of the code will port directly, of course, but the integer mathematics would and so would the smooth-framerate algorithm. If I am successful in making a vector-graphics engine for the Propeller, then I could represent the graphics as line start->end points and not need a bitmap or the overhead of drawing lines to one (a cog would translate the line data to pixels as the screen scans). An engine that supports triangles would really be nice but I never worked out the math to do surfaces; my 3-d pipeline only handles points and lines. I wrote it in high school and figured out all of the 3-d pipeline math with just what I learned in algebra 1 and using thought experiments and graphs drawn on napkins. I hadn't had trigonometry when I started so I didn't know what the SINE function was - I used another program to generate a table of values that was essentially a sine table; rather than finding sine by trigonometry it actually used a "guess and check" method to fill the table with values that would make the rotation come out right! I also had to "invent" rotation matrices but I didn't think of them as matrices; I just called it "the xness of x' plus the yness of x' " and "the xness of y' plus the yness of y' ".

Linerider would also be a great game to make on the Propeller.

AndreL

Well, even to draw lines you need a bitmap buffer. There are REALLY clever ways to get around it for example. You can have a vector list then on the fly as the rasterizer is drawing scanlines you render the lines as the scanline intersects them, kinda a scanline slice algorithm. But, not recommended if you do want to do filled polys, but still possible. To get any decent sized games·you will have to write your own graphics engine and tv driver and code in pure ASM since with the bitamp buffers and engine, you will have little space to make a 3D game in spin. But, if you use tile engines then you can definitely use spin to make small games since you don't loose the 24K needed for double buffering of a decent resolution.

I didn't write a 3D engine for the hydra, but I might in the future. However, the book CD comes with an eCopy of my "Black Art of 3D Game Programming" which covers 3D rasterization, the entire 3D pipeline, poly filling, etc. and was written with DOS in mind, so its very applicable to the propeller. Of course, its all in C and 80xxx ASM, but algorithms are algorithms. In any event though, all the 2D games you mentioned are easy to write with my "HEL" engine or some of·the more advanced 256 color engines we developed. But, asset pipelines are a bit of a problem. I created one tool chain to get bitmaps and tile worlds into the hydra using my engine, but for your engine or the other demo coders engines you have to use other ones.

But, to give you an idea, with my HEL engine or the other engines we made, a 2D game like asteroids, or pacman, etc. takes about a weekend to a week if you code without stopping and have it in your head what you're doing already.

Andre'

Bergamot

It occurs to me that the filled-polygon scanline problem would be an ideal use of S-Buffers, as long as the polygon count remains relatively low.

Dennis Ferron

I was thinking that while one cog is drawing a scanline, another cog can be quickly finding just those lines/filled polygons which cross the *next* scanline, regardless of where they intersect it; then when the scanline is actually rendered the pool of contributing visual elements would be smaller.

Bergamot

Dennis Ferron said...
I was thinking that while one cog is drawing a scanline, another cog can be quickly finding just those lines/filled polygons which cross the *next* scanline, regardless of where they intersect it; then when the scanline is actually rendered the pool of contributing visual elements would be smaller.

Well that's exactly where S-Buffers excel; you break the screen down into horizontal strips, so your polygons get chopped into lines. Do hidden surface removal on those lines, and in the end you get a list of all the horizontal spans you need to draw to the screen buffer. No wasted time, because you don't have to draw a pixel multiple times like you would with the Painter's Algorithm, and as long as you don't have really small polygons, it uses much less RAM than a Z-Buffer. The other nice thing is that you only have to update the list when your scene changes, which doesn't have to be every frame.

Does the Hydra come with a fixed-point math library?

AndreL

No, fixed point object since for every game/demo the fixed point stuff changes so much, its best to just code a custom fixed point lib yourself how you like it.

Andre'

AIman

Could this

·videodisplay.out(3)

Be used to identify a color on a screen?

Mike Green

What do you mean "identify a color"? Which display driver (the out() codes vary)?

AndreL

AIMAN,

I think you mean by looking at the color on the screen you can make a list of colors? The best thing to do is run a palette program that shows the whole palette with your TV set to neutral tint. Then make a list of those color words or palette byte descriptions then go into the video display object or whatever you are dealing with and look how it refers to colors / palettes and then change the palette entries to reflect the sub-set of colors you want. There can only be one set of 4 colors per screen tile, so that particular driver "videodisplay" might use the same for all tiles. I haven't played with this one. But, bottom line is there are two ways to determine the ACTUAL colors;

1. Generate a palette on the screen that shows all colors and all shades (which we have done at nurve) and then screen grab them and sit with photoshop and determine the RGB value of each.

2. Make a math model considering that the color burst is phase delayed and broken up into 16 different colors eqidistant, then use the YUV calculations and the intensity values to come up with an RGB model then try a few test points and see if what you put in comes out on the screen. I have done this as well.

IN REALITY though, the TV has different gamma, the phosphors are NOT equally responsive, nor is your eyes, so in the end a hand generated palette taken from actual screen grabs on 3-4 sets was averaged and I created 2 palettes, one that looks "ok" on most things when you do an RGB conversion, and one that looks REALLY good on some stuff, and bad on other stuff. Welcome to the world of color matching in video game / graphics hardware and trying to make what you see on your VGA monitor come out the other end on the NTSC screen [noparse]:)[/noparse]

Andre'

potatohead

Been looking at the assembly TV driver.

(Man, what an interesting assembly language BTW!)

Seems to me, there are two issues: Color as Parallax did it, and whatever you want to do. It's all software and bandwidth limits. Use one COG, get a few colors or some resolution. Use more than one COG and get more colors, overlays, etc....

Andre: Did you end up programming the equilivent of hardware collision detection? Was picturing one cog drawing a background and another COG doing sprites. As the sprite COG draws, it should be able to read what the other COG has contributed to the video output and detect a collision with drawn pixels. If you ended up doing this, care to comment on how it goes in general?

AndreL

There are a number of graphics engines that were written. We wrote drivers that use multiple cogs in a parallel way, so one cog is rendering another one is processing tiles and sprites at the same time. The engine I wrote for the book is a lot easier to understand than our parallel engines. The one for the book is called the HEL engine and is commented to death. It uses a SINGLE cog, but does, tiles, sprites, scrolling, and has a tile map that is row dominant, where each tile is a tile index and a tile palette pointer, very easy to work with. Then you can have up to 8 16x16 sprites with sprite clipping and z-overlays, they of course take on the color of the tile they are over.

The engine is a good starting point and shows all the advanced concepts needed to make more advanced engines. It shows how to scanline buffer things, creating a display list of sprite scanlines that need rendering per line, caching techniques to bring in frequently accessed data to localmem, and lots of other things.

The most advanced engines use up to 7 cogs and run in parallel, support, many, many sprites, smooth scrolling, tiles, and 256 colors [noparse]:)[/noparse]

Andre'