http://binarydemons.com/~strike/files/eng3d.rar


both versions
---------------------------
-floating-point color representation
-easily extendable to include alpha blending, including user-defined blending operations (add, subtract, multiply, invert, etc)
-double buffering
-depth buffering
-gouraud shading
-affine texture-mapping
-non-power of two texture sizes


dos version only
---------------------------
-screen resolution 320x200 8-bit (fullscreen)
-colors implicitly mapped to 323RGB (8-bit)
-source code included (compiled with Borland C++ 16-bit compiler)


win32 version only
--------------------------
-any screen resolution or color depth (windowed or fullscreen)
-colors implicitly mapped to 888RGB (24-bit)

But what does it do?

It seems to be a graphics engine.

It doesn't do perspective correct texture mapping?

What about Z-geometric alpha flip-flopping?

What can we do with it? Can we play games with it?

I see what you did there.

although there are things you can do in a software rasterizer that would be difficult or even impossible to do with shaders, there is really no point to using a software rasterizer these days, unless you are working in an environment that does not support hardware 3d acceleration..

like cell phones for example. or flash actionscript. or even COG for that matter.


hmm.. that last one about COG gives me a horrendously devious idea.. this is the part where you should either become very scared or very intrigued.

An individual surface to represent each pixel. A texture with multiple cells. Switch the cell to change the color of the pixel. It would be awesome. But also very, very slow.

yes, but theres more to it than that to make it powerful.

need back buffer and depth buffer to make it useful to render 3d.
can store the backbuffer and depth buffer within the unused surface/adjoin/face flags of the surface, that way i can keep the heap free for other things if i need it. using those unsupported flags would cost no extra memory too since the memory is already allocated for each surface.

multi celled mat was one idea, but could be a bad idea in implementation. although a 1x1 single color material cel could be used and not consume very much memory, there could be other potential overhead to that approach; especially if you want to try to emulate a reasonable number of colors. to make it a feasible approach, i would have to treat the cel indices as the actual color value itself, like how the DOS raytracer works. for 256 colors i had to take 8 bits and split it up three ways: 3 bits for red, 2 bits for green, 3 bits for blue. pretty lousy color resolution when you can only mix 7 shades of green/blue with 3 shades of green.

what i think im going to do is just make the display single-color, or grayscale. the result wont be 'full color' but it will at least look smooth. instead of using material cels, ill just change the surface's extra light value to set the 'color' of the pixel.

if i could specify the alpha for translucent surfaces i could do full color without more than 3 materials, but jk doesnt allow that and that approach would triple the surface count, which could really impact framerate..


now i just need to finish this jed plugin to subdivide a surface into evenly sized grid squares given a desired width/height in cells and i can start the cog.. :downs:

heres a little proof of concept of the JK idea
http://binarydemons.com/~strike/files/jkscreen.wmv

the video is really choppy primarily due to me using a crappy screen recorder instead of fraps. no joke, framerate is 10x higher without My Screen Recorder

That will be awesome if you get it working right. Please post a screenshot as soon as you have a triangle rasterized, before you worry about any of the 3d transformations.

Though, shouldn't the set surface light call account for the fact that the first surface in the grid might not be surface 0? And is it safe to assume the grid surfaces are all laid out the right way?

that sector is generated by a plugin i wrote. i add the grid surfaces first; left to right, top to bottom. then the other walls of the sector.

ordering and placement of the grid cells was a concern initially. naturally it is simply not practical to specify each surface in the cog window in jed, nor is it practical to cleave up the surface by hand.

at first i was thinking i might have to make u specify the surfaces that are not part of the grid, then i would build an array (on the cogheap) of which surfaces correspond to which 'pixel index' by finding surface centers and sorting appropriately when the cog starts up. this would be way too much of a hassle in terms of extra cog code to write, wasteful usage of cogheap, and slow down backbuffer presentation (when i actually set surface light values to display the image). making a plugin to autogenerate the sector (and autogenerate it in a specific manner) was the major key. specifying the grid width/height and the surface that represents pixel 0,0 is enough

oh god what have you done

heres another pic, i changed the mat to solid white, and the glow is dynamic light from a bryar bolt hitting the wall

the smooth shading (gouraud) on the triangle is part of the rasterizer.

true double buffering is already implemented. depth values are already being generated per-pixel so im a hop away from implementing true depth buffering as well.

That's cool. I'm not sure how useful it would be, though. I can see a couple of good uses the technique could be put to, but it would depend on performance issues.

Jon`C doesn't have much of the programmer mentality for a programmer, does he?

Scary and perhaps useless, but awesome.

I'm in the same boat as Jon lol

this is interesting but it'll be useful around the same time we're running PS2 emulators written in Java.

I demand an NES emulator written in COG.

O_o