Topic awaiting preservation: 3D SoftWare Engine: group effort anyone?

Anyone interested in helping developing a Software Renderer? For CAD or otherwise?

If so: maersklandro@yahoo.com. Thanx.

Mind you, just because you're paranoid doesn't mean they're not out to get you!

What's in it for me?

On which platform and language to want to code that renderer ?
And what kind of thing do you aim ? a realtime renderer ?

For Dos: Vesa 2 and above using TP 7 - priority. Windows 2000 and above in FreePascal using Grafx2, not started yet.

Developing efficient, assembler-optimised code is the priority. Porting to other platforms/languages comes second.
I will share ALL my code with anyone willing to help after they contribute of course. that is what is in it for you .

Mind you, just because you're paranoid doesn't mean they're not out to get you!

(Edited by sonyafterdark on 10-06-2004 10:36)

Pascal
And do you want to render realtime animations or still images ?

Whatever, if I want, and find the motivation, to work on 3D stuffs in my spare time, I'd work on a demo project in either OpenGl or DirectX ... or eventually in Java.



(Edited by poi on 10-06-2004 11:04)

I said assembler optimised not normal pascal code :P. It's a software renderer, OpenGL is hardware supported but restrictive and inefficient. Same with DirextX. Java is the last thing I would use. I am striving to overcome inherent speed limitations by sheer code efficiency. For example differentiating between rotation and translation movements so you don't do rotations unless you have too, using c-buffering, etc.

If I manage to do it, it will be all the more rewarding .

Mind you, just because you're paranoid doesn't mean they're not out to get you!

Sorry, I don't have a great souvenir of the months I coded in Pascal.

OpenGL is restrictive and inefficient ... tell this to John Carmack

DirectX is not only Direct3D. You can use only DirectDraw to setup the framebuffers and screen swapping and do all the rendering by yourself in software. Years ago I've coded some toys with DirectDraw in VC++ and optimised some parts by hand coding some MMX assembler routines.

As for JAVA, it's not that slow. The JAVA demo scene productions and those of Equinox prooves that some pretty and fast things can done with it..



(Edited by poi on 10-06-2004 12:11)

One of the things i am trying to optimize is to avoid recalculating the memory address for each pixel even if I burst-write a row of pixels to a framebuffer as I am texturing scanline by scanline. Only calculate the memory position for the first pixel of the burst and add one byte or two or... as i go through the row, depending on the current colour resolution. Actually, with c-buffering, no calculating of screen position is ever needed because you write from the top left corner to the bottom-right, pixel by pixel not randomly like in a Z-buffer so you only need to increment the memory address by the colour depth increment. I am pretty sure DirectDraw recalculates the memory address each and every time you put a pixel to a framebuffer. Even if they are always next to each other and the order is left - right because you use c-buffering not z-buffering. That is one of the reasons I am not using DirectDraw.

The reason i am not using OpenGL is because it is impossible to apply true c-buffering to OpenGL either, obviously.

And i am not about to learn OpenGL or DX programming if neither fits my needs.

Mind you, just because you're paranoid doesn't mean they're not out to get you!

quote:

---

I am pretty sure DirectDraw recalculates the memory address each and every time you put a pixel to a framebuffer.

---

You didn't read what I said let's say it again : you can use DirectDraw simply to do the graphic setup and only the graphic setup.
That way you avoid the troubles of playing with VESA libraries. With DirectDraw you can retrieve a pointer to the LFB ( Linear Frame Buffer ) of the screen and use it at will to write your pixels ( via something as easy as: LFB[ x+y*screenPitch ] = newColor; or *LFB++ = newColor; ). Of course you'll have do the clipping by yourself, sorting your pixels with the method of your choice ( be it a Zbuffer, an Sbuffer, a Cbuffer or who knows what ). Actually you don't need to know much about DirectDraw to do that because everything you need is in the very first sample code of DirectDraw. At least it was the case in the SDKs of DX6 and DX7.

You haven't yet tell if you want to do render realtime animations or still images.



(Edited by poi on 10-07-2004 10:17)

anyone care to explain me what is c-buffering and what s-buffering?
thanks!

cBuffer and sBuffer are some methods used to avoid the overdraw in 3D rendering. Actually if you render the objects from back to front it is clear that some pixels of the screen will be set sereval times for nothing and thus some machine time will be wasted. That's why some people have elaborated some methods like sBuffer or cBuffer.

There's a good explanation of cBuffer, sBuffer and other techniques on Flipcode.com, and in Paul Nettle's S buffer FAQ.



(Edited by poi on 10-07-2004 17:48)

quote:

---

as easy as: LFB[ x+y*screenPitch ] = newColor;

---

<x+y*screenpitch> is exactly what i am talking about. this is a redundancy especially when using C-buffer, incrementing is far better. I assumed that you can't access the LFB directly and that you have to use a putpixel proc., whether you want to or not, and that it would automatically do the mul and add. 10x. I will look into it.

And yes, i already have images moving cursively, with lots of polys(not textured yet but hundreds), even on my PII at 233, thank you very much :P .

And yes, it's made in Pascal. Version 7 for Dos, mind you. There is not that much of a difference between C and Pascal and, believe it or not, some things are actually faster in Pascal.

Everything but the Vesa library(Grafx1.4 http://www.crossfire-designs.de ) is "home developed and made". But thanx for caring . The only timing function used yet is the tipematic delay.

I also have a 2D-line clipping algo. all of my own. I mean i developed it on my own but that doesn't mean somebody else wasn't there first. Fast too.

Trouble is it is only possible to apply C-buffering without simply y*screenpitching when in mode13h... which i am not developing for. I hate it, the damned pixelated thing. I want my engine to run up to 32 bits per pixel and 1024*768, using Grafx1.4 and maybe 2 in the future.

Oh, and i was under the impression that Windows 2000, XP and the like don't very much appreciate liniar frame buffering and that this is a sticky compatibility issue caused by the crappy Dos emulation. If ever it is used these days it is for compatibility with old gfx cards.

Sorry for the long post.

Mind you, just because you're paranoid doesn't mean they're not out to get you!

quote:

---

as easy as: LFB[ x+y*screenPitch ] = newColor;

---

<x+y*screenpitch> is exactly what i am talking about. this is a redundancy especially when using C-buffer, incrementing is far better. I assumed that you can't access the LFB directly and that you have to use a putpixel proc., whether you want to or not, and that it would automatically do the mul and add. 10x. I will look into it.

And yes, i already have images moving cursively, with lots of polys(not textured yet but hundreds), even on my PII at 233, thank you very much :P .

And yes, it's made in Pascal. Version 7 for Dos, mind you. There is not that much of a difference between C and Pascal and, believe it or not, some things are actually faster in Pascal.

Everything but the Vesa library(Grafx1.4 http://www.crossfire-designs.de ) is "home developed and made". But thanx for caring . The only timing function used yet is the tipematic delay.

I also have a 2D-line clipping algo. all of my own. I mean i developed it on my own but that doesn't mean somebody else wasn't there first. Fast too.

Trouble is it is only possible to apply C-buffering without simply y*screenpitching when in mode13h... which i am not developing for. I hate it, the damned pixelated thing. I want my engine to run up to 32 bits per pixel and 1024*768, using Grafx1.4 and maybe 2 in the future.

Oh, and i was under the impression that Windows 2000, XP and the like don't very much appreciate liniar frame buffering and that this is a sticky compatibility issue caused by the crappy Dos emulation. If ever it is used these days it is for compatibility with old gfx cards.

Sorry for the long post.

Mind you, just because you're paranoid doesn't mean they're not out to get you!

quote:

---

<x+y*screenpitch> is exactly what i am talking about.

---

That's why I also gave the *LFB++ = newColor; example

quote:

---

Trouble is it is only possible to apply C-buffering without simply y*screenpitching when in mode13h... which i am not developing for.

---

I suppose you say that because in mode 13h the PITCH is equal to the WIDTH ( and since it's an 8bits color depth mode, the PITCH is also equal to the WIDTH multiplied by the color depth ). S buffer and C buffer algorithms are scanline based, so I see no problem with the fact the PITCH may be different from the WIDH or the WIDTH multiplied by the color depth. Once a scanline is processed you have to do ONE addition :

LFB += PITCH_minus_WIDTH_multiplied_by_the_COLOR_DEPTH;

Since you want to use some ASM routines here and there, you can also auto-modify the code to replace the use of the PITCH_minus_WIDTH_multiplied_by_the_COLOR_DEPTH by its absolute value.

quote:

---

Oh, and i was under the impression that Windows 2000, XP and the like don't very much appreciate liniar frame buffering and that this is a sticky compatibility issue caused by the crappy Dos emulation. If ever it is used these days it is for compatibility with old gfx cards.

---

Arranging the video memory linearily (?) is the most efficient method. Why would they dump it ? The use of PITCH that may be different of the width ( mutliplied by the color depth ) is also another example that the linear arrangement is made to be efficient since it aligns the scanlines on memory segments ( of 4, 8, 64, 512 or 1024 bytes ) to avoid every possible alignement stall when the video memory is accessed.

10x, but i'm still not gonna pick up on DirectDraw or anything else yet, cause i'm to lazy to learn it or winapis and all that. When i will, i'll probably be using Venomgfx library, perhaps you know it. Or maybe you could point me to something better?

Oh, and the reason i've started this venture is mainly to develop algorhytms, not really a finished project but an engineering sample people can use the essence of to port to other languages and OS.

I am currently working on developing perspective corect texture mapping on my own.
I've been working on this a few days and i've found that you have to do a sqrt each scanline of the screen polygon, in order to get truly accurate results. This can't be right, can it?


There is a trick i thought of: when texturing, you store the last V and last U texel coordinate you calculated for the last screen pixel and after you calculate the current V and U texel coordinates for the current screen pixel, you average the Red, Green and Blue values respectively of all the texels that cover the area inside the texture vertically between last V(not including) and current V, and horizontally between between last U(not including) and current U. The result is the one you use at the current screen pixel. the effect you get is one of antialiasing INSIDE the texture.

Maybe somone can use this?

None of this is tested yet. Most not even written.

And how come you know so much about 3d? It says there: javascript, xhtml. css, not OpenGL, DD, etc...

Mind you, just because you're paranoid doesn't mean they're not out to get you!

(Edited by sonyafterdark on 10-11-2004 10:56)

And how come you know so much about 3d? It says there: javascript, xhtml. css, not OpenGL, DD, etc.
I have more than one string to my bow I only mention my "web skills" in my sig ( and resumé ) because they represent my main interrest at the moment. But in fact the Computer Graphics are the primary thing that attracted me to computers and computer science when I was a child. I've been in the demo scene, alas since I work as a web developper I don't have the time to code for "real". Nonetheless I keep an eye on the demo scene and on some coding techniques.

AFAIR, there's no need to compute one sqrt per scanline. What you have to do is to interpolate the inverse of the Z, thus you need to do one division per pixel. To speed up the process you can interpolate the inverse of the Z every 8 or 16 pixels and then lerp ( Linear intERPolation ) the pixels in between. That's what John Carmack did in Quake 1. Stick to a wall and turn at ~90°, the mapping should swing a bit if the interpolation is done every 16 pixels ( there's a parameter to set it every 8 pixels in the console, but I don't remeber its name ).

The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.

Well, not all graphics cards work best with OpenGL. For example, the latest card from Nvidia performs best with OpenGL applications but the latest one from Ati performs best with DirectX ones. Also DirectX is not only about graphics. It's almost all you need to develop games. And DirectX 9.0 C is not the same with 7, for example. Let us not forget shader 3.0, etc.

Mind you, just because you're paranoid doesn't mean they're not out to get you!

The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.

ah well InI, there are some graphic cards which are OpenGL optimized and there is definitely a difference in performance to DirectX.

for example the 3DLabs wildcat card.

it always depends on what version of DirectX or OpenGL the card has implemented.
not all have DirectX 9 and not all have OpenGL 1.5

The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.

excuse me InI, but you are getting offtopic.
i was talking about that depending on the hardware OpenGL and DirectX can perform differently.

i did not say anything about their features.
i did not say anything about java or poi (whose demos are amazing, no doubt)
i did not say anything about the demo scene or your group.

and that article: even there it says that there is a graphics card that does not support DirectX.

The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.

Ini, are you female? You strike me as a female ;D. Also, i think "bitchiness" is a female attribute. if you're a girl, the attitude is arrousing(did i spell it right?), otherwise, plain annoying.

Do they have girl groups where you come from? What were you in charge of? Music?

And i am not trying to reinvent the wheel, i am trying to invent the racing slick :P.
I'll try to remove my head from between my buttocks(did i spell it right?) and place it back on my shoulders, if ever it was there. But before i do that, why don't you respond to these:

1. I'd like to see fisheye projection in OpenGL, or D3D, for that matter. I'd prefer it be yours.

2. Also, I'd like to see how you succeed in applying s-buffering or c-buffering to OpenGL and/or D3D.

3. Furthermore, i'd like to know if you've developed a line or poly clipping algo all on your own.

4. Have you made even something as trivial as a point inside triangle test?

5. Or maybe camera position offsets for smooth rotating about arbitrary points in space.

{6. Or at least texture antialiasing. Maybe using OpenGL?} oops, didn't read your post. I am humble before you. How old are you anyway? 17 myself, wise old creature of the forest.

When you're done answering these, I'll post a few more. No matter. I've got plenty.

How does one go about implementing realtime shadow casting in OpenGL, i'd really like to know that. i don't think it is even possible. Not to mention soft shadows.

And what's up with your logo?

Mind you, just because you're paranoid doesn't mean they're not out to get you!

(Edited by sonyafterdark on 10-13-2004 13:06)

sonyafterdark: I know your previous post is addressed to InI, but I can reply most of your question.

1. In OpenGL and DirectX you can simply render the scene to a texture buffer and then use that texture as a cube map you'll project onto a sphere or a cube and voilà, you can even apply a pixel shader to render the scene as seen through bumpy crystal ball.

2. s-buffer and c-buffering makes no sense in hardware rendering. A Z-buffer is implemented in hardware, so there's no way to beat it.

3. hum, you should have a look at the applets and demos he has done.

4. is it really necessary to answer to this ?

5. cf 3.

6. Texture antialiasing ? Come on, bilinear and trilinear interpolation were already implemented in the 3DFX 1. And antializing of the edges can be enabled in both OpenGL and DirectX.


About shadow casting in OpenGL, there's several methods to it. The most trivial being to render the scene in flat from the point of view of the lights and let the zBuffer do all the magic. You can also project the shadow volume and let the stencil buffer do the rest. About soft shadows, you can use a render to texture ( again ) at a downsampled size and project the rendering from the lights sources and use the stencil buffer to cast it only the objects beyond the object casting the shadows, or you can use some pixel shaders too.


I don't mean to be harsh, but it looks like you haven't seen any hardware rendering during the last 8 years. Have you seen some games like Quake III Arena, Splinter Cell, Halo, Unreal Tournament 2004, DOOM 3, ... they have some dynamic lighting, shadows, amazing rendering modes, depth/localized blur, motion blur, bump mapping, specular highlights, ... all done in hardware and works in realtime.

You should really have a look at the developer pages of nVidia and ATI, and some site talking about shaders like shadertech or CGshaders to realize the real capabilities of current hardware.

I understand your intent to develop a software engine for learning purpose, but you seem to have some wrong preconceptions about the capabilities and speed of hardware features.



(Edited by poi on 10-13-2004 14:30)

The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.

The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.

Castor?! I really thought you were a girl at first ;D. No, i don't think Castor would like to marry a "82 kilogram girl" :P. Besides, i am underage, friend ... Castor "Geek factor"?! missing define.

What is the name of the group ini? And what is the country of origin?

In light of all that has been posted... Yes, it does seem i am a bit behind the times .(a few years worth)
That's what reinventing the wheel is all about. (even if it is a bit oval)

I had absolutely no f**king idea that "texture antialiasing" thing was actually biliniar filtering. Guess i was so exctatic about discovering it, i never considered that.

Whoa Poi, slow down. I an writing in FreePascal and you want me to get into GPU and shader programming?!
Though i do have a copy of NvidiaC on my drives, but alas, the sloth in me reluctantly submits to learning.

Also, for the time being i have no site of my own uploaded anywhere. I will maybe fix that in the near/far future depending on my lazyness factor.

In the meantime if you really want pics and stuff, mail me at <maersklandro@yahoo.com>. I will answer sporadically cause net coverage where i live went poof and disappeared a while ago and i have to do all my net affairs from school, which i also attend sporadically ;D.

Otherwise, please don't tell me I'm all talk and no show.

Mind you, just because you're paranoid doesn't mean they're not out to get you!