Oldschool: Software Render

[calc84maniac]

Software rendering on my TI-84+SE is epic.

 

[God Ginrai]

Software rendering on my TI-84+SE is epic.

Have you made any games for it? (I see your sig) Also, have you ever worked on the TI-89?

-God Ginrai

 

[Exophase]

Doing stuff in OGL is just easier when it fits. There are of course things that hardware just can't do without a lot of working around and major efficiency hits, even with shaders. This is especially true on a TBDR like SGX. To this day there are still some very creative and optimized software renderers being done. It'd be interesting to use the DSP, since it can do multiple non-contiguous loads/stores simultaneously, which is useful for things like texture mapping. But since you're not doing texturing at all I'd say you don't have a lot to worry about. You also won't need to bother with perspective correction, which is another thing that's a total pain in a software renderer.

One big thing you have a lot of freedom on is how you perform hidden surface removal. Scanline based with is a good idea - you can do this with span sorting or scanline depth buffer. I'd stay away from doing a framebuffer-wide depth buffer like a typical IMR would, because that'd totally eat L1 cache. For the same reasons scanline based is a lot better for alpha blending, if you decide to have that. A span based sorting algorithm could also handle blending w/o the need to sort the polygons scene-wide ahead of time.

 

[calc84maniac]

Software rendering on my TI-84+SE is epic.

Have you made any games for it? (I see your sig) Also, have you ever worked on the TI-89?

-God Ginrai

This would be my latest one: http://www.ticalc.org/archives/news/articles/14/145/145336.html
And I mostly used my TI-89 for playing games.

 

[GuchaRU]

Your poll options are incomplete; you miss at least "if it fits the app, its okay". ie: Not freak, not hater, just in between or 'as appropriate'.
jeff

initial idea of poll was "is ppl ok with software render?" so it's ok as it is

One big thing you have a lot of freedom on is how you perform hidden surface removal. Scanline based with is a good idea - you can do this with span sorting or scanline depth buffer. I'd stay away from doing a framebuffer-wide depth buffer like a typical IMR would, because that'd totally eat L1 cache. For the same reasons scanline based is a lot better for alpha blending, if you decide to have that. A span based sorting algorithm could also handle blending w/o the need to sort the polygons scene-wide ahead of time.

i think i'm going to use "ray tracing" to each map cell in that part of map that player face. and knowing that even entire map won't be larger then 100-200 cells won't take much of a time to calculate visible and hidden cells. and after that i'll draw this cell's walls.

also i do not planning to add "mouse look", only arrows to let player turns around and move forward and backward.

I think all game will be around about 300-400 lines of code

 

[God Ginrai]

Software rendering on my TI-84+SE is epic.

Have you made any games for it? (I see your sig) Also, have you ever worked on the TI-89?

-God Ginrai

This would be my latest one: http://www.ticalc.org/archives/news/articles/14/145/145336.html
And I mostly used my TI-89 for playing games.

Oh my god. I love Chips's Challenge! ^_^

-God Ginrai

 

[Enverex]

How is a software renderer any better for the end user? If you like how it looked then just make it so that it uses a Hardware renderer (to get more speed) while not using any of the available image enhancements such as mip-mapping, etc. It'd look exactly the same as the software rendered version, only it'll put the correct parts of hardware to use rather than just hammering the CPU.

 

[lulzfish]

Yeah... I'll tolerate software rendering, but if you're just drawing vector graphics, you could add OpenGL acceleration pretty easily and reduce the CPU load to like nothing.

On the Pandora it's just a waste to let the GPU idle while the CPU is running line-drawing algorithms that the GPU could do in hardware...

 

[GuchaRU]

Yeah... I'll tolerate software rendering, but if you're just drawing vector graphics, you could add OpenGL acceleration pretty easily and reduce the CPU load to like nothing.
On the Pandora it's just a waste to let the GPU idle while the CPU is running line-drawing algorithms that the GPU could do in hardware...

well, probably you are right... but I'm actually never coded using openGL, i'm web programer and know only basic stuff about system coding so i decide to make really simple game in my free time just for fun and to gain some exp
Also i'm using free pascal for linux arm. I know it's pretty lame XD but this is my first game for win/linux ever
I'm good at php,mysql and such stuff (even coding browser online stratgy) but i know nothing about normal coding

 

[WizardStan]

well, probably you are right... but I'm actually never coded using openGL, i'm web programer and know only basic stuff about system coding so i decide to make really simple game in my free time just for fun and to gain some exp
Also i'm using free pascal for linux arm. I know it's pretty lame XD but this is my first game for win/linux ever
I'm good at php,mysql and such stuff (even coding browser online stratgy) but i know nothing about normal coding

This would probably be a pretty good way to start then. Drawing lines in OGL is really simple, and would give you a good feel for the flow of hardware accelerated titles.

 

[Exophase]

well, probably you are right... but I'm actually never coded using openGL, i'm web programer and know only basic stuff about system coding so i decide to make really simple game in my free time just for fun and to gain some exp
Also i'm using free pascal for linux arm. I know it's pretty lame XD but this is my first game for win/linux ever
I'm good at php,mysql and such stuff (even coding browser online stratgy) but i know nothing about normal coding

If you are in fact doing polygons then OGL will be easier than writing a software renderer. If you're just doing ray casting then it'll be pretty easy to do it in software. For each line shoot a ray out, find the first wall it intersects with, use the distance to determine how far back to draw the wall and what color to shade it. You could even shoot rays out on a bitmap, rather than comparing against a list of vectors. You'd have to be sure to get the perspective correct on the wall depths and use dot products to properly light them or else it'll look funny - take my word on this one.

 

[Mr.Confuzed]

This would be my latest one: http://www.ticalc.org/archives/news/articles/14/145/145336.html
And I mostly used my TI-89 for playing games.

Definitely checking that out. Edit: "The blue button controls the tanks. The green button toggles walls. Sometimes things are hidden under blocks." Lol blue, thanks calc84maniac.

OT: Funny you mentioned software rendering, I've been thinking about/working on a software rasterization concept that would allow you to draw curved surfaces. So no, there is nothing wrong with software rendering even today. Not to mention, with shaders, your graphics hardware is running software too.

 

[wardred]

As long as the game works, I don't really care what it uses. If software rendering makes the game run too slow, then that's a problem, but heck, I remember the original quake on a 16mhz 386. Software rendering for certain games should certainly be doable on the Pandora.

Somebody else's point about drawing lines with OGL is certainly worth bearing in mind.

 

[PokeParadox]

The hardware acceleration will likely be of benefit regardless of the look you are going for. You can always disable filtering if you are looking for are more retro look and still get the benefit of offloading the rendering onto hardware made for... urm... rendering.

A lot of the oldschool software rendering techniques can in fact be adapted to take advantages of today's hardware and still, if you wish, fall back to a pure software renderer if needed (but that's not really a problem on a Pandora.)