New Game IDEA! :-need lead programmer for colors(256 or more) and controller:
Bob the Builder on a C64
Posts: 112
Quantum lance 3D!:
Well, right now I have 8 of the 512 images for the sprite for the character(belive it or not, my job is so much harder than the people who plan to help me.) The reason it will use so many images for the sprites, is because I am implementing barrel roll. For the game I will take the scaling code from The X-Racer game, and make it use my sprites, get rid of the road, add the insane colors, make it allow for complex movement by joystick. And make the stars scale, also add movement through a more vast scale!
If anyone will help be the lead programmer for this idea/project, please speak. I'm the one with the hardest job, so don't be so intimidated by it. Also, this game will NOT fit in the 32 KB In fact, it doesnt' matter how much memory your code takes up, as long as it is not greater than a gig(which is highly improbable)
Comments? look at the attachment to see my current work
Note: This is only 1/64 of how many sprites I'll be making.
Well, right now I have 8 of the 512 images for the sprite for the character(belive it or not, my job is so much harder than the people who plan to help me.) The reason it will use so many images for the sprites, is because I am implementing barrel roll. For the game I will take the scaling code from The X-Racer game, and make it use my sprites, get rid of the road, add the insane colors, make it allow for complex movement by joystick. And make the stars scale, also add movement through a more vast scale!
If anyone will help be the lead programmer for this idea/project, please speak. I'm the one with the hardest job, so don't be so intimidated by it. Also, this game will NOT fit in the 32 KB In fact, it doesnt' matter how much memory your code takes up, as long as it is not greater than a gig(which is highly improbable)
Comments? look at the attachment to see my current work
Note: This is only 1/64 of how many sprites I'll be making.
330 x 250 - 2M
52 x 52 - 503K
Comments
And don't totally commit to sprite or tile art for 3D, the propeller is definitely fast enough with a better graphics engine to do bitmapped 3D with filling. You just have to get rid of the per pixel onscreen test that the parallax driver uses to fill polys, take it out of the loop and the number of polys/second will go up quite a bit. Of course, you are stuck with 4 colors, BUT, once again, you can tile the color space, so each 16x16 screen space can at least have its own 4 colors. Then you can stick to a bitmap only display which is much easier to code than tile+sprites.
Something to think about --
Andre'
I need help on: 3D modeling for the Hydra,Colors,Joystick controller programming,Flipping of sprites and usage:
Can you please tell me some data to get me started on some of the project?
Thank you.
Read my book, then try and make a simple 3D model rotate around on the screen, then try and model it as polygons with faces and normal vector, do a simple hidden surface removal algorithm, then up the tech with a sorting algorithm, painters algorithm is fine for this stuff, then you get a "camera" system working and you have a rudimentary 3D engine something like that was common in the late 80's early 90's.
OR you can try a "ray casting" engine which I cover as well in the book which is the approach wolf3d takes.
Andre'
I'll probabilly be able to get rid of the road and change it to stars and stuff, then add sprites that scale elsewhere on the screen, but to start, I need Code examples on Flipping sprites,A simple Scaling code (derived from X-racer)A simple 256 color obj(derived from the "Glass" demo) and the Keyboard·obj that uses one cog.
I have the following: The keyboard object,some sprites,Sound concept(in progress)
I need the following: 256 Color obj,Simple scaling code,sprite flipping demo/obj,hueing demo/obj
I will be able to do these: Simple scaling code,256 color obj(possibly)
I need help on these: Hueing,Color and Sprite flipping
progress:= 6%
·As for the 3D model, I will try it out and see if I can get anywhere.
Thank you alot Andre!
Will you give me some examples for hueing code,flipping code and simple scaling?
As for sound, I know exactly what I'll do, but It seems I'll have to wait to get the sound into HDMF format.
Please help!
Also it sounds like you are starting out with too big of a project. Start smaller, make a pong or tetris or pacman first. Also you are not going to get more that 60 some colors out of the Hydra, that limit is fixed.
Start off using Andre's video driver and make a game. Then learn asm and make your own video driver that meets all the needs you are looking for. No one else is going to do any programming for you outside of code that has already been released.
Just remember, start smaller. Make a Pong.
I'm calling it the */ ("star slash") 3-d engine.
Also: Can I use the engine when your finished? and: Do any of you have some simple scaling,sprite flipping and raycasting code examples·or hueing code examples?
Edit: An important point for understanding what follows is that the edge of a triangle, and a line, are the same thing. The key idea is that if you know how to draw a line, then you know how to draw a triangle.
Let's say you draw the whole screen scanline by scanline (the way a TV driver works). Suppose you are drawing a scanline that passes through a triangle. What you want to know, in order to fill in the right pixels, is what X coordinate the leading edge of the triangle crosses that scanline at, and what X coordinate the trailing edge intersects the scanline. If you color in the pixels of the scanline between the leading edge and the trailing edge, then you correctly color in one horizontal slice of the triangle on each scan.
A simple way to do this is to use math to figure out where the lines intersect. You can figure out the slope of the line using "rise over run," in other words taking the x distance traveled and dividing by the Y distance traveled between your two line endpoints; that's your rise over run, your slope. Once you have the slope, you can start with one endpoint and figure out the X location that it intersects it by multiplying the Y distance between the scanline and the endpoint, by the slope. The thing is, this is slow because it involves a divide and then a multiply; it's inefficient to do that on every scanline.
You may notice that a line moves a regular amount of pixels left or right as it goes along. Instead of recalculating the slope and intercept every time, it is much faster to re-use the value of the last intercept and add a constant to it to get the new intercept. Once we have a starting line endpoint, we calculate the slope value one time, and we find the x-intercept for the next scanline by taking the last value and adding just a small incremental value to it (the slope of the line over just one Y increment). This is very similar to the Bresenham line drawing algorithm, except that it is even simpler. In order to draw a line, you have to figure out which of the four quadrants you are in, and whether the line is more vertical or horizontal. But to draw a triangle, you simply generate "enter" and "exit" locations for the leading and trailing edge, and it doesn't matter if the edges are sloping forward or back, or more or less than 45 degrees, it will still get filled in correctly.
Overlapping triangles can be handled like this: you precalculate all of the "enter" and "exit" points for the triangles, and put them into a list. If you want to impose a Z-ordering or the painter's algorith, you can then juggle the points in the list to get whatever draw order you like. Whether or not you apply Z-ordering, you then pass the enter-exit list to cog running a finite state machine scanline renderer with a special stack. Whenever it encounters an "enter" symbol, it pushes that triangle's ID onto the stack. When it encounters an "exit" symbol, it searches the stack and removes that triangle's ID (it may be or may not be the topmost one on the stack). Any time it needs to draw a pixel, it looks at it's stack and draws the color of the topmost triangle on the stack. If it runs out of triangles on the stack, it draws a background color (such as sky or stars).
This may be fast enough to generate TV output directly from a triangle list without any intermediate bufferring (saves you the RAM usually required for a screen buffer).
Also your render sounds interesting because in theory you could run it at 60 FPS since it is rendering on the fly, it would just run at the speed of the 3D calculations for the list.
So instead of rendering the next scanline, we SKIP the next scanline and render the one after THAT! In one swoop we recoup our speed losses and regain our triple buffering. But what does the TV driver render when it catches up to the scanline we skipped? It goes back and displays the old scanline pixels over again! Will you really notice one line of doubled pixels in a busy image? The algorithm degrades gracefully - at best you can operate near peak triangle capacity all the time with very little glitching. At worst, the whole display drops down to one-half normal resolution but nearly doubles "max" triangle throughput!
It seems like we've been thinking on similar lines. Although it sounds like you're taking a top down approach, and I'm taking a bottom up one.
To me and I think you too, The Hydra Way is never to use screen buffers, and always to generate scanlines on the fly. That mitigates the Hydra's weak point - lack of memory, and leverages it's strengths - multiprocessing, and software generation of the TV signal. So I've got a nice TV driver and renderer object pair that's adaptable to any type of graphics output.
Fantasia isn't really intended to be a text TV driver at all. I just did text as the first output to facilitate future debugging needs. The idea is to produce a hi-color vector driver. So the plan is bitmaptext->particles->vectors->vectortext. That much I'm definitely going to do. But of course once you've got vectors, then wireframe 3D becomes quite tempting. And filled triangles are also a logical progression from drawing lines. I'm not sure that I'll progress to 3D, but I might not be able to resist the temptation.
As both yourself and Andr
Dennis, I've been thinking about·making a TV display driver for rendering.
I'll do a prototype, and post it.
See how it looks.
Baggers.
·
I'm a bit confused with the Hydra really, but if you would give me code examples for those, well...I bet I probabilly could get more work done!
What I need is Code examples for the following I said before,explanation of each code example, so I can finish the code examples and make them slowly more advandced to work with what I'm doing.
You said something about accidentally ignoring JT Cook! Well that's a shame because he gave some good advice for you. I'll repeat it for you.
It's good advice. You're asking for advice and code snippets for rather a lot of the things that you need to do for a 3D program. Which means that you're probably aiming too high for your first project. You have to start simple and work up. Pong is a good idea, or breakout, or for more of a challenge, Space Invaders or Pacman. But you certainly don't want to be starting out doing a 3D game if you don't already know how to do a 3D game AND have a very good grasp of multiprocessing and the Propellor chip
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
All I need is an examples and some explamation of code·for me to get more than just sound and sprites/modifications done.
Soon I'll show you a program for the music I've got!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Realize that I am really a mad scientist··· and
Don't forget it!
http://raydillon.com/Images/Illustration/GameArt/WildIsle/WildIsle-Ink-ScientistClose.jpg
Post Edited (Bob the Builder on a C64) : 6/8/2007 2:57:46 PM GMT
What·I need is examples in order to implement that stuff. pretty much, but it seems potatohead has the 400 color thing now..so I think I'll use that if I can!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Realize that I am really a mad scientist··· and
Don't forget it!
http://raydillon.com/Images/Illustration/GameArt/WildIsle/WildIsle-Ink-ScientistClose.jpg
Post Edited (Bob the Builder on a C64) : 6/8/2007 2:57:56 PM GMT