Developer Thread

[Dan East]

This thread is for communication between programmers working on Pocket Quake. Please don't post to this thread if you are not participating in Pocket Quake development. Thanks.<br><br>Dan East<br>

[Dan East]

Jacco, Carpediem; I've added a new variable which allows the user to control how many particles are rendered at most (the default was 2048 ). The new var is:<br><br>r_maxparticles<br>The range is 0-2048, or if a -particles command line parameter was specified ("-particles p" ), then the range is 0-p.<br><br>Previously this could be modified via the command line ("-particles" ), which is not the preferred mechanism for making settings of that kind. The command line parameter can still be used to increase the maximum number of available particles if more than 2048 are desired.<br><br>Just to prevent you guys from doing the same thing...<br><br>Dan East<br>Last modification: Dan East - 02/27/01 at 05:05:35

[Phantom]

I'm still struggling with CalcGradients. Starting to look better (using some angles I can distuingish textures:), but this will take some time... I have plenty of time tonight (I think), so it should be fixed by tomorrow. Boy, is this a mean bastard. <br>I didn't notice a very big speed gain from your modified actor CalcGradient, btw. Did you time it yourself? I expected it to matter more.<br>BTW, cool thread. To be honest, I just wanted to post something. )

[Chris Edwards]

Want me to move this thread to the General Developer Discussion board?

[Dan East]

I get .2 fps increase with the int-based CalcGradients. Even if an optimization results in only a theoretical increase, I'm all for it if it doesn't reduce the visual accuracy. <br><br>Reducing the particles to 100 using the new r_maxparticles variable increased fps by .3. 100 seems to be a good value because you can still see rocket / grenade trails, blood spray, and enough particles for decent looking explosions. It basically prevents the big slow-down resulting from the massive particle explosions of normal Quake. Those using slower devices could prevent all particle effects from occuring.<br><br>I've been having a hard time getting real consistant fps readings regardless of the technique. It seems like I get a substantially higher (.5 fps) reading just after I first build and download a new version, so I've been throwing out the first result. Subsequent runs are slower and consistant. Of course I reset the device and start fresh each test. This is one of the reasons I saw a 24% performance increase with your first optimization, while others didn't realize that large of an increase.<br><br>Chris; I'd rather this stay in a Pocket Quake category, because it is totally specific to the project at this time. BTW, according to the Forum List this forum is in the " Developer" category already. Perhaps a new forum could be created for general PQ discussion?<br><br>Dan East<br>Last modification: Dan East - 02/27/01 at 07:52:42

[Phantom]

Dan,<br><br>I developed my 3D engine and some upcoming stuff on my PC by using OpenPTC for the graphics output. OpenPTC provides you with a very basic window and a buffer (palettized or any other bitdepth) in wich you can simply draw. Maybe it is a good idea to port Quake to OpenPTC, to ease the development. That would allow all coders to work on the PC (I for example don't have an USB cradle, meaning that I have to wait for ONE MINUTE to test EACH NEW VERSION). This could seriously ease the fixed point coding. I'll see what I can do tonight.<br><br>Jacco.

[Dan East]

Will it work with CE? Besides the user input, Windows is not used at all for output (and shouldn't be) - we directly access the screen buffer. The current code should build for Win32 without too many modifications.<br>I use the emulator extensively for testing new routines before finally going to the actual device. Besides the inability to do Landscape, the emulator has been very accurate as far as the alogithms go (and besides the fact that it is blistering fast).<br><br>Dan East

[CARPEDIEM]

How hard is it to make pocketquake C++ compatible and then make a fixedpoint class and replace every keywork float or double for the corresponding class name.<br>I've worked on a class such as that when i was making a fractal test for a benchmarking tool that i made, but quitted on the attempt because i found a much easier solution.<br><br>Come on Jacco!, get Windowz 2k! it rocks!<br><br>Last modification: CARPEDIEM - 02/27/01 at 09:43:04

[Phantom]

Carpediem,<br><br>That class is not going to work, since we need varying accuracy in the integer part and the fractional parts of the fixed point numbers. It WOULD however be very nice if we would have a fixed point class with adjustable precision (int/frac), and small pieces of ASM code for multiplications using 64bit intermediate results.<br><br>By the way, I finished that CalcGradients function last night. I need to fine tune a couple of things, and I have to fix the sprite code a bit, but after that I have a rather large amount of new stuff for you guys:<br><br>1. The CalcGradients function is now fixed point and calculates the texture projection matrix in fixed point too, so the conversion of this matrix to fixed point by the scan renderer is no longer neccessary<br>2. The span renderer and the z-span code are now merged (that's faster, of course, especially since those functions contain mostly the same code)<br>3. The sky is now drawn without perspective correction (unnoticeable)<br><br>That's about it. Maybe some small changes, but this is the main part. I will fix up the sprite code and send Dan a long list of instructions to merge this with the original code. After that, I consider my job done, and I will continue to work on 'new' software. <br><br>- Jacco.

[Phantom]

Hey all,<br><br>I have just sent my latest modifications to Dan. Changes include:<br>- Affine textured sky<br>- Completely fixed point texture projection matrix<br>- Fixed point 'turbulence' textures<br>- Joined z-buffer/pixel span rendering<br>and some more that I forgot. I hope Dan can tell you all how much it matters.<br><br>I will stop here; I'll let other coders take over now. I'm back to my other pet projects.<br><br>Greets,<br>Jacco.

[CARPEDIEM]

Well i'll try working on the keyboard this weekend. I know the problem comes from the modifications i did when altering the drawing funcions. <br>You see Dan, i modified some things on the drawing function, And i know that's why the keyboard is not showing. <br>the problem is that i have to open "(*GXBeginDraw_)();" and close the frame buffer everytime i want to display the image. Otherwise the screen won't refresh. <br>Actually, i have no idea of why it works on the ipaq, the only way to display the contents of the framebuffer that i know of is by using <br>(*GXEndDraw_)(); <br>

[CARPEDIEM]

So, the thing is that when i call (*GXBeginDraw_)(); the framebuffer is filled with the screen contents and they don't include the keyboard, and when i close the framebuffer, the screen is redrawn, Drawing over the keyboard. So i believe that's why people can't see it.

[CARPEDIEM]

Anyway, i guess you received the new optimizations by jacco, How to instert them is pretty well explained but you'll get 4 simple compilation errors. You can quickly fix them by inserting these lines:<br><br>extern int fpxscale;<br>extern int fpyscale;<br>extern int fpxcenter;<br>extern int fpycenter;<br><br>Right before<br><br>static fpvec3 mo;<br>static float tmo;<br>void D_CalcGradients (msurface_t *pface)<br>{

[Dan East]

I've got it built with the modifications. I also had to define fpvec3 in mathlib.h:<br>typedef int fpvec3[3];<br><br>What type of performance boost have you seen? I get around .2 fps increase.<br><br>Dan East

[CARPEDIEM]

Dan, can you help me out with the drawing function?<br>Can you explain to me how do you draw on the ipaq?<br>This is the way i know how to write on the framebuffer.<br><br>1) Ask for a pointer of the framebuffer.<br>2) draw over it<br>3) draw on the screen by closing the framebuffer<br><br>You don't seem to do that with the ipaq version i got.