ProQuake 4.70 PSP Build

[Baker]

I don't know. Skyboxes use a lot of memory for a system with very little of it.

[dr_mabuse]

i am thinking about to fake the sky with "fog" command , it looks better than the "Quaked sky"

[ceriux]

the texture alignment thing looks bad no matter what

[Baker]

the texture alignment thing looks bad no matter what

Can you provide more information? Like what does this affect, did this affect Kurok PSP or did I introduce this problem (maybe in 4.70?)?

I ask because ... well ... I don't run 4.70 because I have private version I have been running for quite a while and 4.70 was a quick spin-off of that.

[The version I run has more features and asks what mod to run upon startup, but I have never been entirely satisfied with the ability to configure it.]

[dr_mabuse]

it only happens in proQuake 4.70, the older ProQuake builds and Kurok didnt have this problem...
Maybe is a conflict with the HLBSP support, but i am not 100% sure.

[Baker]

it only happens in proQuake 4.70, the older ProQuake builds and Kurok didnt have this problem...
Maybe is a conflict with the HLBSP support, but i am not 100% sure.

Thanks for infos. With that information, I should be able to identify the change that caused this issue.

[dr_mabuse]

Looks like the error didnt happen with HLBSP maps
I still got some strange PSP freezing with my mod on ProQuake and Kurok at some areas of my maps...
Removed the soldier enemy and it didnt crash anymore.. Strange

[Baker]

I *do not* like crashes.

In truth, there is PSP mod I will be releasing. And I will want the engine stability to match.

I probably have +5 skill over 1 year ago. We'll see what this means. I do know the release of this PSP mod and the next engine will be same day. We'll just have to see which day in the next 3 weeks this ends up being, but it is going to happen. I think double tap support in the engine is something I'll do just because Downsider thought it was a good idea and fleshed out his concept enough and tested it and we are only talking 10 PSP buttons, besides Jukki or Blubs (or one of those guys) thought it was a good enough idea to do QuakeC side.

I never did think that ProQuake 4.70 was good enough, but life has detours ... but detours are temporary even if they last longer than you ever thought.

[frag.machine]

I probably have +5 skill over 1 year ago. We'll see what this means.

Baker (opening the eyes): I know Quake Fu!
MH: Show me.
(Everyone at Inside3D runs to watch)

[mh]

I'll be watching this one with considerable interest. The hints I've had so far of what Baker's up to have been quite tantalizing, and anyone levelling up their skill can only be a good thing for everyone.

[Baker]

Perhaps not the most interesting screen shots ...







One feature in Engine X is the ability to expose tons of information to the developer / mapper ...

I thought I might as well throw at least one item from my stash out there.

[1. To ProQuake PSP peoples ... ^^ those shots have nothing to do with ProQuake PSP, just so you know.
2. I have max_fps set to 72. Engine X (with everything on) is faster than anything except DirectQ. MH's lightmap experiments was one part of it. Then I found another big one. Then I mtex'd everything. There are like 3 or 4 other interesting optimizations I made, I can't recall them all at the moment. I have one more in the works ... this one will result in FPS gain ... but I'm not doing it for frames per second. There is something I want badly that just isn't quite possible without it ... and it'll unlock some really great stuff
3. Obviously since I have FPS set to 72, screenshots above tell you I do not have client/server timing separated. Yet ... ]

[mh]

I'd love to see you beating me for performance if you can pull off that other idea. It's quite cool to see the old notion that "the Quake engine can't handle big maps/open scenes/horde combat/etc" being blown away, and another engine that can do it will be to everyone's good.

I suspect that you may need to go D3D to get all the way though; I've profiled OpenGL as bottlenecking CPU-side in the driver a good bit higher than D3D does (part of it may be having to support all the legacy API crap, as well as translate an API that doesn't really mirror the way modern hardware works into something that does). But I'd still love to see it (and if nothing else it would mean that I can get more speed out too!)

You're not going to beat RMQe in scenes where every surface has animating styles and there are 30+ dynamic lights going off at the same time though; I'm quite confident of that one! DirectQ can't come even close to that.

Correct, it's not just about raw performance, although raw performance in smaller maps does translate into decent performance in bigger/more complex maps so it remains a good thing to shoot for.

[Baker]

Large scenes: Engine X chokes on the big area in Arwop's first map with monsters like every standard engine.

I'd love to see you beating me for performance if you can pull off that other idea. It's quite cool to see the old notion that "the Quake engine can't handle big maps/open scenes/horde combat/etc" being blown away, and another engine that can do it will be to everyone's good.

Actually, I'm not trying to beat DirectQ, nor was my goal to beat any other engine. I wanted to get rendering with everything on fast enough that there would be no good reason to feel like you wanted to turn stuff off.

So my goal was entirely different. I do not believe in "game options".

But to back up the concept of "no game options", this means that for example underwater caustics, dynamic lighting and particle rendering need to be fast.

I am going for "works so good 'out of the box' that you won't be looking for options". Someone looking for "options" is a design failure in my opinion.

My "final speed up" has a different goal ... I want the entire scene finalized before rendering (for a few different reasons including being able to capture the state of a frame and save it to disk or load it from disk or browse it).

I might as well give this post some PSP relevance, at least theoretically ...

Code: Select all

typedef enum
{
//   FitzQuake limit                // Standard limit (WinQuake)
   MAX_EDICTS_PROTOCOL_666         = 32000,  MAX_EDICTS_PROTOCOL_15      =  8192, // Baker: Although WinQuake only supports 640 edicts, the protocol can handle up to 8192 correctly.
   MAX_FITZQUAKE_SANE_DEF_EDICTS   =  2048,  MAX_WINQUAKE_SANE_DEF_EDICTS   =   640, // Baker: These are my arbitrary values.  The latter number keeps compatibility, the former is just sanity.

   MAX_FITZQUAKE_MSGLEN         = 32000,  MAX_WINQUAKE_MSGLEN         =  8000,
   MAX_FITZQUAKE_DATAGRAM         = 32000,  MAX_WINQUAKE_DATAGRAM         =  1024,

// per-level limits
   MAX_FITZQUAKE_BEAMS            =    32,  MAX_WINQUAKE_BEAMS         =    24,
   MAX_FITZQUAKE_EFRAGS         =  2048,  MAX_WINQUAKE_EFRAGS         =   640,
   MAX_FITZQUAKE_DLIGHTS         =    64,  MAX_WINQUAKE_DLIGHTS         =    32,
   MAX_FITZQUAKE_STATIC_ENTITIES   =   512,  MAX_WINQUAKE_STATIC_ENTITIES   =   128,
   MAX_FITZQUAKE_TEMP_ENTITIES      =   256,  MAX_WINQUAKE_TEMP_ENTITIES   =    64,
   MAX_FITZQUAKE_VISEDICTS         =  1024,  MAX_WINQUAKE_VISEDICTS      =   256,

   MAX_FITZQUAKE_LIGHTMAPS         =   256,  MAX_WINQUAKE_LIGHTMAPS      =    64,

   MAX_FITZQUAKE_MAX_EDICTS      = 32000,  MAX_WINQUAKE_EDICTS         =   640,
   MAX_FITZQUAKE_MODELS         =  2048,  MAX_WINQUAKE_MODELS         =   256,
   MAX_FITZQUAKE_SOUNDS         =  2048,  MAX_WINQUAKE_SOUNDS         =   256
} engine_limits;

#if HIGH_MEMORY_SYSTEM

#define DEFAULT_PROTOCOL   PROTOCOL_FITZQUAKE
#define ALLOW_PROTOCOL_666   1                           // Normal.
#define MAX_EDICTS_CAP      MAX_EDICTS_PROTOCOL_666            // Maximum dynamic possible.
#define DEFAULT_MAX_EDICTS   MAX_FITZQUAKE_SANE_DEF_EDICTS      // Default statically allocated amount, default dynamic cvar value.  Baker: I do not foresee us using static in the future.

Code: Select all

#if SUPPORTS_EXTERNAL_ENTS // Earliest point we can read the entity string, since we need the model loaded.
   if (external_ents.integer && (entitystring = (char *)QFS_LoadHunkFile (va ("maps/%s.ent", sv.worldname), sv.worldmodel->loadinfo.searchpath /*PATH LIMIT ME*/)))
   {
      Con_Printf ("External .ent file: Using entfile maps/%s.ent\n", sv.worldname);
      // To do: Maybe set some cvar to the .ent file name
   }
   else // Either we aren't using external ent files or we didn't have one, load the old fashioned way
#endif
      entitystring = sv.worldmodel->entities; // Point it to the standard entities string

   Con_Printf ("Entities count of 'classname' in entity string is %i\n", (sv.entities_string_count = COM_StringCount(entitystring, "classname")));


#if VARIABLE_EDICTS_AND_ENTITY_SIZE
   // Baker: If maxedicts cvar is 0, take the entities count and add host_maxedicts_pad to it.  Otherwise use host_maxedicts value
   sv.max_edicts = host_maxedicts.integer ?  host_maxedicts.integer : sv.entities_string_count + host_maxedicts_pad.integer;
   sv.max_edicts = CLAMP(MIN_EDICTS_FLOOR, sv.max_edicts, MAX_EDICTS_CAP);
   Con_Printf ("Setting server edicts maximum to %i edicts\n", sv.max_edicts);
#else
   sv.max_edicts = DEFAULT_MAX_EDICTS;
#endif

   sv.edicts = Hunk_AllocName (sv.max_edicts, pr_edict_size, "edicts");

I might be able to, with no small amount of work, get Engine X to run on a PSP If you see the memory implications of the above ... (those huge static arrays to support protocol 666 aren't going to work, but I can build the engine for protocol 15 only support ... and with that second block, I can have both the client and server support entities beyond 640 and keep it all dynamic without a user ever having to touch something like a max_edicts cvar).

[dr_mabuse]

sounds nice so far, does Engine x supports HLBSP?

[Baker]

sounds nice so far, does Engine x supports HLBSP?

It happens to support that, but this is going to be in many ways a very niche engine and generally uninteresting to general purpose modders (many things do not work in the "traditional way" and there are a fair number of them). But will be a fun source of writing some tutorials for hardcore engine authors. I've so far solved a lot of fun little problems and I have 5-6 more I want to do. Engine X is really more geared towards supporting modding projects on my hard drive I want to complete and I'll be continually changing the rules (and arguably implementing unstandard methods ... some of which I hope to get standardized at some point in time).

And I can do niche stuff in Engine X and weird experiments because almost no one is using it.

I shouldn't have posted Engine X stuff in this thread really.