Version 0.051 released for mips

[CARPEDIEM]

Well, it finally is working. There are two issues as far as i know<br>1) the keyboard is not working properly, but you can get around the problem with some info i included<br>2) when you switch to landscape mode and then back to portrait mode the menu no longer draws. i mean, the control menu, where you attack and jump etc etc.<br><br>well, it runs at 7.8 fps on my E-125 @ 200 with the provided autoexec.cfg<br><br>I think it runs a whole frame per second slower if you put the .pak into the main memory, try using a compactflash card and decompressing it.<br><br>well, i think that's it the file will be posted on the main page tomorrow i think the address is <br><br>c ya guysLast modification: Chris Edwards - 03/15/01 at 18:10:10

[Jeff]

thank you thank you thank you thank you thank you<br><br>you are the man

[Dan East]

Download it here with this link (or from the download page):<br>http://www.pocketmatrix.com/pocketquake/PocketQuake0051_MIPS.zip<br><br>Dan East

[Moose or Chuck]

I only get around 6.8 on my E-125 @ 180. I think I'll overclock mine to 200 now.

[CARPEDIEM]

Well, you probably won't get an extra frame just by overclocking it to 200. First make sure you are using the provided autoexec.cfg and that you have the pak file decompressed in a compactflash card.<br><br>On other notes, i forgot to update the version number on the about box so i think i'll do that now. Also, Dan could i get some credit on the about box like: carpediem: mips debugging or something?<br><br>I also forgot to say that when you are running on landscape the esc key is mapped on top of the screen and the fire key on the bottom. You might have to change the key conf when running on that mode, just go to options and then to controls, Or modify the autoexec.cfg if you want.<br><br><br>Last modification: CARPEDIEM - 03/16/01 at 06:55:38

[Dan East]

The control skin should work properly, at least it does on the iPaq and in the emulator. Did you build using the newer 0.051 source I uploaded?<br><br>Dan East

[CARPEDIEM]

No i didn't build it with the build you posted that fixed the landscape mode.<br><br>The control skin suffers the same problem that the virtual keyboard. This is what happens:<br><br>On mips devices, when you call on begin draw, the the framebuffer contains the actual screen.<br><br>So, if you try to open up the keyboard, it will be displayed, but just for a little while until the next frame of the game is updated. When it is, the keyboard graphic is overwritten with the contents of the old framebuffer, that is, a control skin without the keyboard. So actually the keyboard is there but you just can't see the graphic.<br><br>When you switch to landscape mode, the area where the control skin was is overwritten with the bigger screen. If you switch back to portrait mode, the contents of the framebuffer still contain a part of the ingame graphics in the area where the control skin is.<br>When you switch back to portrait mode, the skin is redrawn, but right after that the screen is updated with the older contents of the screen. Therefore you see the game on the upper half of the screen, and part of the ingame graphics you got in landscape mode in the lower half of the screen, instead of the control skin.<br><br>

[Dan East]

That still doesn't make sense. If the only thing in the video buffer retrieved by BeginDraw is what you wrote to it last frame, then the skin should never be visible. How does it get into the video buffer then when you start in landscape mode?<br><br>Dan East

[CARPEDIEM]

Well, i guess i didn't make myself clear in the last post. I'll try to make explain the keyboard issue, the skin problem is the same.<br><br>(some things are on the screen (not the keyboard)<br>-) gxbegindraw() <br>    gives me a pointer to the framebuffer, whose content is filled with the current contents of the screen.<br>-) Here i start drawing pocketquake's screen on the upper half of the screen and the user pops up the virtual keyboard, (Which is displayed on the screen over the control skin). Note that when i draw pocketquake's screen i only write until Y == 180. So the lower half of the Virtual Framebuffer remains intact (the skin contents are there, still intact, with no keyboard whatsoever)<br>-) gxendraw() Refreshes the entire screen with the contents of the framebuffer. That way the skin with the painted keyboard is overwritten with the old skin, which had no keyboard drawed over it.<br><br>So theorically you could get to see the keyboard if you opened it up right between gxenddraw and gxbegindraw. But that's practically impossible since the time between them is very very small.<br><br>So the solution lies there, the skin problem should be easy enough to fix. You just should detect when the user switches back to vidmode 0 and there intentionally close the buffer, repaint the skin, and open the virtual framebuffer again.<br><br>I tried to do that but i had no success in making it repaint again. I sent the WM_PAINT message to the correspondent function and it didn't answer. I didn't try hard enough at that time because there were other more important issues to resolve and im short on time.<br><br><br>Last modification: CARPEDIEM - 03/16/01 at 08:55:36

[Dan East]

So theorically you could get to see the keyboard if you opened it up right between gxenddraw and gxbegindraw. But that's practically impossible since the time between them is very very small. <br><br>To the contrary, Pocket Quake is not multithreaded. It is absolutely not possible to open the keyboard, or for a WM_PAINT to occur (where the control skin is blitted) during VID_Update, as it does not contain a message pump. Some other mechanism is responsible.<br><br>Dan East

[CARPEDIEM]

If i am wrong... <br>Then why if you open up the keyboard in the about box (before begindraw is called) the keyboard remains always painted?<br><br>Anyway, some people are experiencing lockups when switching to landscape mode, let's remove the mips file until that can be solved.<br><br>Last modification: CARPEDIEM - 03/16/01 at 09:29:51

[CARPEDIEM]

The file is back up again, i hope the problem is fixed.<br>

[Daedelus]

There is a grey area problem with this release, I experience it too. It looks like it has something to do with players distance and angle facing. Sometimes, instead of seeing a grey area, I can see through doors and see enemies standing there waiting for me to open the door. I can't believe more people aren't getting this problem because it's happening all through the levels.<br>:) It's faster, though.<br>Unable to use landscape because the keyboard disappears when you switch modes.

[Daedelus]

I also noticed the startup cache is 600k now.

[yamiyam]

Ok guys,<br><br>I followed the instructions for the MIPS version.  Copied the v1.2 gx.dll to my windows directory, put pak0.pak.gz on a CF card (10MB) with the included autoexec.cfg and put the quake executable in \windows\start menu\programs.  I get this error:<br><br>   W_LoadWadFile: couldn't load gfx.wad<br><br>What am I doing wrong?<br>