I was perusing the BUILD source and I was curious as to where the Backface Culling code would be. I'm coding an engine that uses lines and a 2D Map to represent the level similarly to BUILD though rendering is a bit different and am currently stuck on Backface Removal.
http://mypage.mtaloy.edu/~jjnst1/newshot.png
I'm working on filling in the tops of sectors, but the only way I can think of to know they are to be filled in is if they are a backface so that is what I'm trying to determine.
In the above screenshot I am just drawing the top of the sector if the back wall has the same sector as the first wall drawn. Which if I am on top of the sector doesn't draw the top of the sector. :D I know pathetic. lol.
But anyway, I was thinking that perhaps the Distance from a Point to a Line Segment Algorithm could help me here because it should return a distance value that is + or - and tell me which side of the line I am on.
<UGH OLD AND UGLY>
Any wisdom you may have on this subject would be greatly appreciated.
Thanks Ken, Joe.
Edited by Jinroh at
Awesoken at
Re: BUILD Backface Removal
In ENGINE.C, search for: //If wall's NOT facing you if (dmulscale32(xp1,yp2,-xp2,yp1) >= 0) goto skipitaddwall;
This is the back-face culling for walls. In Build, dmulscale32(a,b,c,d) is a 64-bit precision version of: (a*b + c*d)>>32. You'll probably learn more from this EVALDRAW script: x0 = 300; y0 = 200; x1 = 500; y1 = 300;
setfont(50,80,1); setcol(0xffffff); moveto(xres/2-100,yres-80); if ((mousx-x0)*(y1-y0) < (mousy-y0)*(x1-x0)) printf("Front"); else printf("Back");
Jinroh at
Aha!
You're a genius Ken, that is a lot more simple than I had anticipated. I appreciate the prompt feedback. The EvalDraw snippet was great as well. I really got a good understanding of what you meant. I usually use JavaScript as my prototyping language, I've used EvalDraw before, but never understood what to use it for before I started prototyping things while I am at work. I really wanna use it more now. :)
Last summer I started a prototyping lanaguage of my own based on well...BASIC lol. It's pretty far along, it executes code well and aside from being not as fast as it could be from checking errors every time a line executes, runs at a decent speed. Like you said about the EvalDraw source, it's not pretty and neither is mine. :D I still have a bit of a ways to go though, Assignment and Expressions currently are PostFix only like FORTH and you can't create custom variables, also there is no input as of yet. It's also not executed on the fly like EvalDraw, just interpreted like any Vanilla BASIC out there.
Anyway, thanks again Ken (hey that rhymes), Joe.
Jinroh at
All right, implemented the backface culling into the engine and now things are going good. Have tons of stuff culled out now. 3 different checks where we can throw things away as well as restructuring of the rendering loop to get rid of unnecessary sin, cos, and sqrt function calls.
Now I just need to fill in the top of the sectors.
Thanks Ken!
Jinroh at
I know this is rather old, but I wanted to update on progress of this engine.
Thanks to Ken's backface code, the filling in sectors is working quite nicely.
I had to go back to Solid Shading for the current moment because my Algorithm is just terribly atrocious. This is currently rending in GDI which is bad enough, but the algorithm is processsing unnecessary wall lines, and such so I've been working on a better way of culling those.
I worked a little frustrum culling algorithm based on the rays created on the periphery of the view frustrum. I just see if the lines created by that intersect with walls and if they don't then they aren't to be drawn.
I have some things to get rid of as well like 4 sin/cos function calls which will be replaced with lookup tables and a SQRT which may need to be replaced with Quake3's implementation of Square Root.
For this round of optimization I hope to at least get it up to 15 FPS which is still pretty terrible, but decent considering it's only like 3-7 FPS at the moment.
Thanks for listening.
Edited by Jinroh at
0xC0DE at
Hey Jinroh.. back and coding again huh ? great!
maybe you can put the source-code on your site so we can throw some tricks at it, and hopefully get the FPS alot higher :) looks cool so far anyway! keep it up!
Jinroh at
Thanks for the encouragement Hugo. Never really stop coding. lol. Just have to travel a lot for work and do other people's coding so I don't get much time to do my own. :(
Anyway, just got the code restructured today and have been giving the algorithm a complete overhaul. I thought of a kind of two pass approach, thinking about this in terms of a 3D Rasterizer where you setup a render list and then render the render list. :D
That should be a lot faster as it will need one sort rather than the very very unecessary 115200 sorts it does every frame currently. Which was fine for the rough algorithm, but now I gotta streamline that sucker.
Let's see how far I can get without having to call you and Ken in for your optimization Hocus Pocus. :D
Jinroh at
Hugo...Everytime I hear your name or read it or whatever. I think of Hugo's House of Horrors. :D Great game.
A small update, a bit old too. Been working on the view frustrum so I retooled back to 2D Mode until I am finished with it.
<OLD>
Edited by Jinroh at
0xC0DE at
hehe.. yeah, there quite some games called hugo (including the adventure games you mentioned).
hehe.. yeah, there quite some games called Hugo (including the adventure games you mentioned). Nice to see your making progress. I’m wonder why the wall on the bottom of the first screenshot is not blue ? The second screenshot seems to select the right walls (assuming you aren’t culling them). Is this on purpose or just a bug?
Jinroh at
Oh yes, good call Hugo! Thanks for reminding me. That was a bug, that I fixed after I took the screenshots. It works fine now. I will post some screenshots of the clipped View Frustrum once I am finished. Then I start working back into 3D Mode. I assume that after all these algorithm changes are in place, I should be able to push the framerate to at least 15 FPS which is very conservative. I have a few additional changes in mind that may push it up to maybe 30 or 60. :D
We'll see this is my Magnum Opus! ^o^ So I am really motivated for this thing.
UPDATE:
Sooo...lately I'm taking a break from the view frustrum these past two days to work on the Editor.
I am certain through absolutely pure coincidence that the editor resembles BUILD's Editor and DOOMBUILDER too. But anyway there is a bunch of toggleable data on the upper left hand corner, as well as, a resizable grid you can lock to as well. When you connect sectors together, the (Magenta Coloured) portal walls are automatically calculated. It's not the prettiest thing, but it gets the job done.
Some things like textures, changing sector heights, and such need to be added yet, but it's coming along quite nicely.
Edited by Jinroh at
Jinroh at
Got some new shots of the 2D View of the Frustrum algorithm and how it clips walls and such.
Re-did the Editor too!
<OLD>
Edited by Jinroh at
0xC0DE at
looks pretty damn sweet! :D
Jinroh at
Thanks Hugo. I know it's kinda boring at the moment. But now I can return back to the 3D Mode and we'll see how much better the framerate is with the view frustrum. :D
I got a better Framerate Counter in my old version and it looks like it peaks at about 15 FPS lowest is usually 5 FPS so we'll see how good I can get it.
Jinroh at
Woot! New Raycaster Update!!
Small video of the current footage. It runs much faster now under Win32/GDI than it did before. So I think now the SetPixel for GDI is the only bottleneck. So I'm going to port to SDL soon.
But as you can see I've got a little bit of a problem with wall sorting so I'm trying to finish that...blah. Don't worry it should be fixed shortly.
There's a shot of the level when viewed from above looking down the hallway so you can see the shape of the level. :D
My renderer is more efficient than even Canvex! MWUHAHAHA!
Edited by Jinroh at
0xC0DE at
Jinroh said at
So I think now the SexPixel for GDI is the only bottleneck. So I'm going to port to SDL soon.