Announcement

**Baker** · 06-21-2016, 02:54 AM

Originally posted by boho103 View Post

Added functionality with "-prompt" menu.

When the "-prompt" command line argument is added to the quake.cmdline file (done be default), the user is prompted to select a mod folder (first option "blank" for default Quake Campaign) upon initial boot of the Insomnia game.

Nice to see someone use some quick engine tips and then actually put them to use in an engine build, which is somewhat rare these days.

Twice as nice seeing someone new do it. And slightly funny MDave has shown up around this same time.

Congrats

**Grzybiarz** · 06-21-2016, 04:24 AM

Huuuuge thank you. I was waiting for someone to make another port of Quake for psp. Im going to test it right now, but im sure it will be awesome. By the way, does it have music support?

**Grzybiarz** · 06-21-2016, 05:55 AM

It does work, but it has some issues.

First of all, heap size is unchangable. No matter what you choose in prompt menu, it will always be set to 34 when you launch the game. It does not only make the game to crash when you start shooting to monsters at map e3m4, but also doesent allow to play Dissolution of Eternity and Scourge of Armaggon Extensions pack, just as in original PSP Proquake.

You put music files in wrong folder. It is put in main directory in "mp3" folder and all music files are named like "02", "03". It causes music not to work. In order to make it working, you need to put it in ID1 directory in folder called "music" and all of the files should be named like this: "track02", "track03". Also BGMtype command should be set to "CD" not "none". All that makes music to work properly. Note that when you put the music is ID1 folder, it will play in every mod and expansion, so forget about diffirent music for each.

I also have a big problem with autoaim. I belive this is an issue from original PSP Proquake. Talking about autoaim which doesent work as it should. It does not only work verticaly but also horizontaly so it makes the game too easy. And it's not like sv_aim command is set to less than 0.93. It should be fixed.

for some reason autoexec file doesent seem to work, but game saves everything that you change in options and put in console, so it's not that big problem.

I really apreciate your work, though. Thanks to this new port, i can easily play all the mods without need to change quake.cmdline everytime. Nice work.

EDIT:
Autoexec works, i just put wrong lines in it before. sorry. I also discovered how to get expansion pack and E3m4 to work. I just changed mipmap ammount to max and chose texture scaling down. To play deathmach without crash, i turned off dynamic lightning, but it is still unstable. To play rapture mod you need to do it all, or else it will crash too. i still can't change the heap, and autoaim doesent work properly though.

**Dark_Duke** · 06-21-2016, 01:13 PM

Originally posted by Grzybiarz View Post

It does work, but it has some issues.

First of all, heap size is unchangable. No matter what you choose in prompt menu, it will always be set to 34 when you launch the game. It does not only make the game to crash when you start shooting to monsters at map e3m4, but also doesent allow to play Dissolution of Eternity and Scourge of Armaggon Extensions pack, just as in original PSP Proquake.

You put music files in wrong folder. It is put in main directory in "mp3" folder and all music files are named like "02", "03". It causes music not to work. In order to make it working, you need to put it in ID1 directory in folder called "music" and all of the files should be named like this: "track02", "track03". Also BGMtype command should be set to "CD" not "none". All that makes music to work properly. Note that when you put the music is ID1 folder, it will play in every mod and expansion, so forget about diffirent music for each.

I also have a big problem with autoaim. I belive this is an issue from original PSP Proquake. Talking about autoaim which doesent work as it should. It does not only work verticaly but also horizontaly so it makes the game too easy. And it's not like sv_aim command is set to less than 0.93. It should be fixed.

for some reason autoexec file doesent seem to work, but game saves everything that you change in options and put in console, so it's not that big problem.

I really apreciate your work, though. Thanks to this new port, i can easily play all the mods without need to change quake.cmdline everytime. Nice work.

EDIT:
Autoexec works, i just put wrong lines in it before. sorry. I also discovered how to get expansion pack and E3m4 to work. I just changed mipmap ammount to max and chose texture scaling down. To play deathmach without crash, i turned off dynamic lightning, but it is still unstable. To play rapture mod you need to do it all, or else it will crash too. i still can't change the heap, and autoaim doesent work properly though.

Thanks for checking it out so thoroughly! Are you certain about the heapsize? In the fat eboot I compiled it works off similar code and only allows you to set a max heap size of 16. I believe the initial console dropdown load parameters print the static default heap sizes and aren't dynamically linked to print the actual set heap sizes. Both the fat eboot and slim eboot will both print their default heapsize params (i believe ~16mb and ~40mb?). I'll look into it more. Thanks for noticing that!

You know, I'm not sure I've ever noticed the autoaim. I'll look into creating another menu param to enable or disable it!

Glad you are enjoying it! I'll start on fixing the bugs

Worth noting, each mod folder has its own autoexec that it uses to load the respective map. The next step for me is figuring out the best parameters for each and including them in the respective autoexecs

Update: you are definitely right about heapsize! While debugging I removed the cpu/heap checkparam pass initialization! I'll add it back in. Good catch!

**Grzybiarz** · 06-21-2016, 01:31 PM

So it only prints that heap size isnt changed? I admit i was just looking at this, because in Juraj Styk versions, it prints actual chosen heap size. I'll try some configurations and tell you how it works.

**Dark_Duke** · 06-21-2016, 02:00 PM

I figured out the issue with heap, I had declared the heap size as a static constant and also had removed the argument from passing from the prompt screen.

I'm at work so I can't do any testing, but if you'd like to try it here is a dev build!
https://www.dropbox.com/s/d4w7upf28k...20472.rar?dl=0

**Grzybiarz** · 06-21-2016, 03:32 PM

It works like a Gold. Heap Now works for real, and even prints it correctly. All expansions pack now works all fine if we choose heap 30. My game still crashes on e3m4 if mipmap isnt on. In both Old and new eboot, game crashes just as i start shooting on deathmach and when Second map of rapture is loading, unless i switch off dynamic lights.

Still it is a big improval because heap size is Now fully changable. Good job

**Dark_Duke** · 06-21-2016, 04:32 PM

Glad to hear its working! I'll modify the mipmap settings to be on by default and try and add some auto-aim prompt options tonight! Looks like I need to release a hotfix

**Dark_Duke** · 06-22-2016, 12:15 AM

Made a few changes, now on Revision 1 :-) See more details in original post. Download link here: https://www.dropbox.com/s/z74ini98ea...0Rev1.rar?dl=0

**Grzybiarz** · 06-22-2016, 08:16 AM

ok here is what changed.
I dont know what have you done, but e3m4, and second map of rapture doese'nt crash while loading difficulty choosing map, but crashes just as i try to load next map. Also, game crashes just as you start shooting on deathmatch mode. both of that doesent make the game to crash, if i disable dynamic lights, though.

mp3 is in correct directory now.

you put "readme" folder in main game directory and prompt menu reads it as a mod folder xd
I see that you added a gl_texturemode line in autoexec. Keep in mind that all of glquake commands doesent work at all. Maybe you feel strong enough to add them?

I also found a mod (?) called dquake, but it looks like it does nothing.

Autoaim is switched off even though it is set on 0.93. I wonder how did you do that.

Still this release is a big improval because, you can now play original quake and most of the mods (and all expansions packs) without any problems and that is a great. Slowly, but surely, this port is better and better.

EDIT: Good news, i managed to play with bots with frobot mod. It obviously demands using disabled dynamic lights and max mipmap on. I played with four bots with no fps drops.

**Dark_Duke** · 06-22-2016, 09:28 AM

Originally posted by Grzybiarz View Post

ok here is what changed.
I dont know what have you done, but e3m4, and second map of rapture doese'nt crash while loading difficulty choosing map, but crashes just as i try to load next map. Also, game crashes just as you start shooting on deathmatch mode. both of that doesent make the game to crash, if i disable dynamic lights, though.

mp3 is in correct directory now.

you put "readme" folder in main game directory and prompt menu reads it as a mod folder xd
I see that you added a gl_texturemode line in autoexec. Keep in mind that all of glquake commands doesent work at all. Maybe you feel strong enough to add them?

I also found a mod (?) called dquake, but it looks like it does nothing.

Autoaim is switched off even though it is set on 0.93. I wonder how did you do that.

Still this release is a big improval because, you can now play original quake and most of the mods (and all expansions packs) without any problems and that is a great. Slowly, but surely, this port is better and better.

EDIT: Good news, i managed to play with bots with frobot mod. It obviously demands using disabled dynamic lights and max mipmap on. I played with four bots with no fps drops.

Thanks for notes, you are the best beta tester one could hope for!

There was a line in one of the source code files that forced cl_autoaim to 1 when the PSP Analog nub was in use. I changed that to "0" by default! If you want it back, I've added it to the config.cfg and its set as cl_autoaim 0 by default now, if you want autoaim back set cl_autoaim 1.

Interesting that e3m3/rapture aren't crashing at same point. When you are running deathmatch, are you playing on an official server or hosting locally with wifi? Neither crash if you have dynamic lighting disabled? If that is the case, it's likely a memory issue. The problem is balancing memory used for the PSP netmodules and Quake itself. With dynamic lighting enabled it's pushing the PSPs performance capability.

Surface caching

When he thought of surface-based lighting, John immediately realized that surface building would be relatively expensive. (In fact, he assumed it would be considerably more expensive than it actually turned out to be with full assembly-language optimization.) Consequently, his design included the concept of caching surfaces, so that if the same surface was visible in the next frame, it could be reused without having to be rebuilt.

With surface rebuilding needed only rarely, thanks to surface caching, Quake's rasterization speed is generally the speed of the unlit, perspective-correct texture-mapping inner loop, which suffers from more cache misses than Gouraud-shaded, tiled texture mapping, but doesn't have the overhead of Gouraud shading, and allows the use of larger polygons. In the worst case, where everything in a frame is a new surface, the speed of the surface-caching approach is somewhat slower than Gouraud shading, but generally surface caching provides equal or better performance, so once surface caching was implemented in Quake, performance was no longer a problem--but size became a concern.

The amount of memory required for surface caching looked forbidding at first. Surfaces are large relative to texture tiles, because every texel of every surface is unique. Also, a surface can contain many texels relative to the number of pixels actually drawn on the screen, because due to perspective foreshortening, distant polygons have only a few pixels relative to the surface size in texels. Surfaces associated with partly hidden polygons must be fully built, even though only part of the polygon is visible, and if polygons are drawn back to front with overdraw, some polygons won't even be visible, but will still require surface building and caching. What all this meant was that the surface cache initially looked to be very large, on the order of several megabytes, even at 320x200--too much for a game intended to run on an 8 Mb machine.

Mipmapping to the rescue

Two factors combined to solve this problem. First, polygons are drawn through an edge list with no overdraw, as discussed a few columns back, so no surface is ever built unless at least part of it is visible. Second, surfaces are built at four mipmap levels, depending on distance, with each mipmap level having one-quarter as many texels as the preceding level, as shown in Figure Four. The mipmap level for a given surface is selected to result in a texel:pixel ratio approximately between 1:1 and 1:2, so texels map roughly to pixels, and more distant surfaces are correspondingly smaller. As a result, the number of surface texels required to draw a scene at 320x200 is on the rough order of 64,000; the number is actually somewhat higher, because of portions of surfaces that are obscured and viewspace-tilted polygons, which have high texel-to-pixel ratios along one axis, but not a whole lot higher. Thanks to mipmapping and the edge list, 600K has proven to be plenty for the surface cache at 320x200, even in the most complex scenes, and at 640x480, a little more than 1 Mb suffices.

Figure Four: Each texel at a given mipmap level corresponds to four texels at the preceding mipmap level.

All mipmapped texture tiles are generated as a preprocessing step, and loaded from disk at runtime. One interesting point is that a key to making mipmapping look good turned out to be box-filtering down from one level to the next by averaging four adjacent pixels, then using error diffusion dithering to generate the mipmapped texels.

Also, mipmapping is done on a per-surface basis; the mipmap level for a whole surface is selected based on the distance from the viewer of the nearest vertex. This led us to limit surface size to a maximum of 256x256. Otherwise, surfaces such as floors would extend for thousands of texels, all at the mipmap level of the nearest vertex, and would require huge amounts of surface cache space while displaying a great deal of aliasing in distant regions due to a high texel:pixel ratio.

One final issue with surface caching involves 3-D hardware accelerators. Surfaces are effectively large textures (and larger at the mipmap levels typically used at the high resolutions of accelerators than they are at 320x200), and texture memory tends to be a limited resource on accelerators. Worse, accelerators are built for 16- or 32-bpp graphics, and surfaces are twice as large at 16-bpp as they are at 8-bpp, and correspondingly slower to build. Although the edge list can still be used to cull invisible polygons, it's nonetheless true that a surface cache around 2 Mb is best on a hardware accelerator.

The first generation of accelerators was originally designed for 2 Mb of RAM, which would have been a squeeze, but plummeting memory prices seem to have solved the problem; 4 Mb is fast becoming the standard. And given sufficient memory, surface caching runs at about the same speed on accelerators as Gouraud shading (slower because of building and downloading surfaces, but faster because of fewer, larger polygons), and still offers the same advantage as in software: detailed and consistently correct lighting.

Two final notes on surface caching

Dynamic lighting has a significant impact on the performance of surface caching, because whenever the lighting on a surface changes, the surface has to be rebuilt. In the worst case, where the lighting changes on every visible surface, the surface cache provides no benefit, and rendering runs at the combined speed of surface building and texture mapping. This worst-case slowdown is tolerable but certainly noticeable, so it's best to design games that uses surface caching so only some of the surfaces change lighting at any one time. If necessary, you could alternate surface relighting so that half of the surfaces change on even frames, and half on odd frames, but large-scale, constant relighting is not surface caching's strongest suit.

Finally, Quake barely begins to tap surface caching's potential. All sorts of procedural texturing and post-processing effects are possible. If a wall is shot, a sprite of pockmarks could be attached to the wall's data structure, and the sprite could be drawn into the surface each time the surface is rebuilt. The same could be done for splatters, or graffiti, with translucency easily supported. These effects would then be cached and drawn as part of the surface, so the performance cost would be much less than effects done by on-screen overdraw every frame. Basically, the surface is a handy repository for all sorts of effects, because multiple techniques can be composited, because it caches the results for reuse without rebuilding, and because the texels constructed in a surface are automatically drawn in perspective.

Excerpt from https://www.bluesnews.com/abrash/chap68.shtml

I'll move the readmes into a different folder, that is funny!

Dquake in there by accident, it was a different quake engine for PSP by crow_bar that had more graphical engine features:
https://sourceforge.net/projects/pdquake/ + https://github.com/st1x51/DQuakePlus

**Grzybiarz** · 06-22-2016, 10:06 AM

Funny thing is that i am not running at any Server (adhoc switch isnt even on) and i just play multiplayer mode with bots. And every map crashes, so problem might be in this game mode. I just noticed that dynamic lights only, causes the game to crash. Mipmap isn't responsible for that.

**Dark_Duke** · 06-22-2016, 10:09 AM

Originally posted by Grzybiarz View Post

Funny thing is that i am not running at any Server (adhoc switch isnt even on) and i just play multiplayer mode with bots. And every map crashes, so problem might be in this game mode. I just noticed that dynamic lights only, causes the game to crash. Mipmap isn't responsible for that.

O.O that is bizarre. I'll need to go through the game mode code. How many bots are you playing with?

**Dark_Duke** · 06-22-2016, 11:26 AM

Originally posted by Grzybiarz View Post

Funny thing is that i am not running at any Server (adhoc switch isnt even on) and i just play multiplayer mode with bots. And every map crashes, so problem might be in this game mode. I just noticed that dynamic lights only, causes the game to crash. Mipmap isn't responsible for that.

So just confirming, you do have Frogbots working in Deathmatch Mode but only with dynamic lights disabled and mipmapping at maximum? Not sure I am understanding

I can't get frogbots to work at all. You did get it working though, correct? What were the settings you used?

Announcement

Insomnia ProQuake 4.71 Engine + MOD Compilation [Sony PSP]

Insomnia ProQuake 4.71 Engine + MOD Compilation [Sony PSP]

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment