Forum archive
Camera roll and mirrors
- So last night i decidet to revive idea of mine and began chcanging pbuild as mi tyny pet engine for gaming experiments. I've decided to go OpenGL polymost only way, so i stripped every func in engine c after call to polymost module and clipped some code in drawpoly etc.
The problem is I don't understand a thing (in math) used there so i recompiled after every strip to chceck whether i haven't broke anything. so far very good all 8 bit thing seems stripped off. Anyway there are some problematic things left - how the mirror is drawn? It seems to me like drawrooms is called once more for every vertical span but i might be mistaken. Anyway my question is can be drawrooms clled to fill any arbitrary trabezoid? even using stencil buffer on ogl to accoplish that would be fine - I am aiming for creating 'window' wallsprite -> an "rectangular" perspectively deformed vieportto another part of the level. Direrct mirrorish vay would be ferfect. Anyway I don't know where to look or what to do. second problematic place seems to be setviewtile or what is the name, there is something for doing this using rendmode 0 but seems like none for using GL backend as feeder.
Another thing I'am interested is rotation of the camera, called roll. Like when duke dies in water. I've read discussion about it here but this is about 8 bit mode only, and I am going to strip that code. Are there some easy global vars to set this in polymost OpenGL mode? That would be perfect.
Anyway I still don't get a thing about how polymost even theoretically. I was thinking about it - isnt it like this? You start with screen filled with one single column, then you pass all the walls in the visible sector to the main polymost function if this wall is facing player/camera, you project it onto sthe starting square and thus create a new column. You do this recursively if the wall is transparent for the sector in which this that wall leads. Am I right? So when you encouter inner wall loop you are just inserting these new columns created by projected wals to the column list splitting any columns slready there?
Yes third thing which is bugging me is how to implement multiple cameras. The code is quite hard orient. Re: Camera roll and mirrors
how the mirror is drawn?
The main view is drawn first. At load map time, the mirror textures are set to null dimensions, resulting in HOM. Drawrooms marks ALL texture indices that were visited during rendering - even if they are invalid. At the end of the first drawrooms, these mirror indices are scanned. If any were visited, then that mirror was visible. Drawrooms is called again with the camera reflected and a global flag set to allow things to work in reverse. Inside the mirror sector, all walls, ceilings and floors are set to a HOM texture, so that it won't overlap any pixels on the front side.can be drawrooms clled to fill any arbitrary trabezoid?
Well, you could do it by messing with the "vsp" buffer in POLYMOST.C, but the math can be tricky with the correct perspective up/down transformation that I do. Shadow Warrior implemented "forward" portals, which worked exactly like a mirror but without the x-flip. Like mirrors, it could only support 1 on the screen at a time.roll ... global vars to set this in polymost OpenGL mode?
Look at:
POLYMOST.C: static float gtang = 0.0;
ENGINE.C: void setrollangle(long rolla)I still don't get a thing about how polymost even theoretically.
Look at: http://advsys.net/ken/buildsrc/default.htm#polymostbas Running the demo will explain a lot. Find a copy of Qbasic.exe and apply the mouse patch if you must.- So after 2 nights I finally ported editor to OpenGL as it was using DirectDraw to draw 2d overhead map. Browsing through code I've found the roll function too, but thanks. By studing Ken's Build - I've found the place where the draw rooms is called for mirror. So I guess that's that first time. After that drawroom is called again to finish rendering? I guess so. Side effect of completely ditching GDI/DDraw is that I could leave a.nasm from my project, seeme to link fine.
So after tidyning more or less everything a bit - still lot of code to strip normlize, I got back to drawrooms. I looked ad the shadow warrior code to check this sector over sector thingy, called there FAF. I am using KenBuild game as reference, and there was some code with comment //SOS. After messing with my patched editor, I placed FLOORMIRROR tile on sector floor, then I created other sector exactly underneath the previous one ceiling at same height like the previous ones floor. with ceiling set to same FLOORMIRROR tile.
Okay so hows the correct way to draw these rooms over rooms?
I can call firs drawrooms(cposx,cposy,cposz,cang,choriz,***); , in gotpic[FLOORMIRROR] with any sector number as parrameter, the room under my feet, belov the magic floor, pops only when I, as player physically enter the floormirrored sector. I checked SW source but thereis only bunch of funct to correctly resolve hitscan through those FAF rooms but when it comes to drawing rooms are drawn exactly like in Kenbuild - drawrooms is called with exactly same params two times. Am I missing something? Or the sectors require some special setup ?
I've noticed some strange sector around FAF pool in SW shareware map, so I tried to duplicate that and created dummy sector with same foolrheight as the low one and ceiling set down to touch the floor like I saw in that SW map but mine FAF works only when I am on the upper floortile sector. So what's the correct setup calling order to acheivethis effect?
I guess that engine won't draw the lower sector if camera is not in some sector, so does FAF lower sector need something around it? I m puzzled nothing seems to work.
I only hope that Warp texture would be easier to hack in. I've given up for the miror/warp sprite for now. - Yes, the mirror drawrooms() is called first, but for a bad reason: in the classic Build renderer, I did not have a chance to make it render sectors natively in reverse (x-flipped). Instead, I hacked it to render mirrors in the normal orientation to the screen. Then in a later step, I x-flipped the whole screen (actually bounded boxes - but you get the idea. See completemirror() for details). Not only is this extra step slow, but it also destroys unrelated parts of the screen buffer. This is why I had to do it first - before the regular drawrooms(). One side effect of having the normal drawrooms() called second is you don't know whether the mirror is visible (via marking of the texture index) until the next frame. If you look carefully, you will notice 1 frame of HOM when you first walk into view of a mirror.
Polymost does it right - it can render rooms directly in reverse (x-flipped). It does not require the slow x-flip stage, but it still suffers from the 1 frame of HOM - that problem lies in the game code.
If you're doing POLYMOST-only, then I would suggest calling the standard drawrooms() first, in which case you can eliminate the first frame HOM problem.
Sorry, I'm not familiar with the hacks the Shadow Warrior team made to allow physics to pass through "FAF".