 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
Good to find the reason afterall.
It was a good opportunity to save them. So much goodies get lost. Thanks for the explanation! I had a quick look at the models from Quake 2 and saw that whoever did them at id Software did a good job overall with the topologies foe the majority of the animated models, but I have yet to find the Quake models. It seems the topologies for the models are equally slick and efficient in execution, but I just need to find somewhere I can have a look at them for studying. If this is illegal to ask for delete posg
I did it guys! I updated the mod. It shouldn't be ear-piercing anymore. Give me feedback. PAK files are also now included. Thanks for your patience. Let's not make this thread another argument about source-ports, okay?
http://bit.ly/seans-better-quality-quake-sounds Q1 models are a mess. Mistakes everywhere.
The artistic skills employed in the Q2 models are much superior, despite some of them being conceptually inferior. Who calls me a mess
Mankrip I would have to think that given it was 1996 and that Quake went through development hell, changing from a flight-sim to a virtual reality game to an online focused mess, the shortcomings of the Quake mdls are deliberate.
The models are not UV wrapped, there is no attempt to pack islands and most skins are direct othographic projections which is massively inappropriate for anything other than planes. The result is stretching, and a lack of detail. Models of other games of the era exhibit better UV wrapping, and in the case of Playstation/N64 games benefited from higher than 8 bit color. Quake 2's mdl2 format did literally nothing to rectify this, although some of its models exhibit better island packing/wrapping. The fact that Quake was software accelerated and meant to be played at a paltry 320x240,combined with Carmacks strict polygon limitations, the artists probably said "no one will notice". The fact that there is not much mesh to work with, it is shocking the animation is as lively as it is, considering the wooden animations of the era. That and there is no skeletal animation system. However, when Unreal came around shortly after with properly UV wrapped models weighted to skeletons, it blew Quake out of the water. And literally every game based on each subsequent iteration of Unreal tech always stole the thunder from same generation id tech games. So ya, study the low poly Lovecraftian meshes, but not the lack of polish that went into them. For some reason, I’m currently getting a deja vu of having already asked this question before. If so, a thousand apologies, I just need a reminder.
The original source code of Quake has these MAX_***** macros all over the place declaring limits for the various elements in the game (entities, brushes, textured, models, whatnot). Understandably so, due to the memory limitations of early PCs and their operating systems. I wonder, however, if modern iterations of the game engine had these limitations all but removed, entirely, considering how nowadays having GBs of RAM, GHz of processor speed, tens of CPU / thousands of GPU cores and TBs of hard drive storage are commonplace for the average computer user. Are these limitations no more in current Quake gaming engines? given the "save every bit" philosophy of the Q1 mdl format (e.g. the "onseam" silliness) I would imagine the lack of UV islands was to avoid having to dupe vertices, increasing the filesize.
I disagree with the Q1 models not being "polished". I think that considering the constraints that teh carmack gave to the artists, plus the state of the modelling apps at the time, they turned out pretty well. Izhido - such limits have been removed where it makes sense to remove them (when I say "remove", that typically means the limit is massively increased to the point where it's not really a limit for the mapper any more) - see engines such as Quakespasm and FTE. Off the top of my head, Sepulchre is probably the best showcase of what modern Q1 map formats, compilers and engines can handle.
Some limits are built into file formats though, and this can make things controversial because to change the limit there, means to change the file format, and all engines have to then recognise and parse the new file format, no-one can agree on what the new format should be, and it's just a logistical mess. Very rarely, agreement happens and so we have the bsp2 file format which lets you make maps that are larger than anyone would really ever need. Got it. So, if I understand correctly, there have been no efforts to introduce dynamic memory management to the engines that would, in theory, remove the need to have hardcoded limits to its capabilities (however high they may be)? I’m asking this just to have my thoughts in order before diving into FTE / spasm / etc source code for answers...
efforts to introduce dynamic memory management to the engines that would, in theory, remove the need to have hardcoded limits
I recall some talk of this in engine threads here, but I don't know to what extent this has been implemented (if at all). I'm at the limits of my knowledge on the subject here, so best check with engine chappos like spike, ericw, metlslime etc. the vanilla behaviour is for map lumps to be consecutively allocated onto the hunk.
this means you don't pay any memory costs for unused faces or whatever. it also means that the engine has no real need to enforce any of those max_map_* limits, it only has the hunk size to worry about. there are some exceptions though, like max_map_leafs that uses various statically sized buffers around the engine, but since Sepulcher neither FTE nor QuakeSpasm have any of those MAX_MAP_* limits remaining (ignoring MAX_MAP_HULLS_hulls which is part of the file format so doesn't really count). Note that file format limits are not always as strict as they first seem. A few limits have been increased by just redefining variables as unsigned, thereby doubling the limit. The most creative expression of this is the max_leafs and max_nodes limits, that still need to share a 16bit index, resulting in some interesting logic to decide whether a node's child is a leaf or a node instead of just checking the sign. The progs.dat format has a similar tweak to double the numpr_globals limit, while being careful to not break statements that do not refer to globals. Either way, just because you CAN have large maps doesn't mean that you should. Or to put that another way, I don't remember to hit quicksave often enough.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |