Know what i would like to see?

[mh]

And other extended limits too? Q1 BSP has a max of 64K vertexes, and there is one RMQ map that's butting right up against that limit and needing continuous work to keep it under.

I actually don't really like the idea of re-uploading sub-regions of lightmaps as a way of implementing lightstyles (due to inconsistent performance across driver implementations, actual performance limits it imposes on lightmap resolution, and a small variety of less significant factors)

It's not that hard to get better performance here, yet we still see engines using wacko formats like GL_RGB and doing a per-surface glTexSubImage2D. I've had one report of an over 90x performance improvement as a result of just switching to BGRA formats and batching up updates.

[Rich]

Rich: what about not being stuck to 3 hull sizes?

Oh yeah, totally forgot about that.

Also, I could've sworn q1bsp used 32-bit edge indices. I'm guessing it's 16-bit based on mh's statement that it has a "64K" vert max, though. Guess it's been at least a couple years now since I touched anything relating to q1bsp.

It's not that hard to get better performance here, yet we still see engines using wacko formats like GL_RGB and doing a per-surface glTexSubImage2D. I've had one report of an over 90x performance improvement as a result of just switching to BGRA formats and batching up updates.

I don't actually think this has a lot of bearing on the fact that it's a generally frowned-upon practice with, still, inconsistent performance across driver implementations. For example, you can just completely forget about it for your iPhone port. Doing "fake" lightstyles would be fine on that architecture, though, with even enough fill to spare on SGX 535 devices to allow blends between two LM lookups in a single page. Not that I think people should design everything around Apple's failures, but it's the best extreme yet practical case that comes to mind of texture region updates sucking total ass.

I can see a reason to keep using this method for compatibility's sake, but when you're talking about a separate path that makes use of light vector+distance maps, you're already requiring shader capabilities. Which means you can just do lightstyle blends with shader operations, so there's no real reason to stick with the old gl method at all in this path.

[andrewj]

Also, I could've sworn q1bsp used 32-bit edge indices. I'm guessing it's 16-bit based on mh's statement that it has a "64K" vert max, though.

Edge indices are 32 bits, but vertex indices (in dedge_t) are 16 bit.

[Ranger366]

This thread seems to be very helpfully to me.
I know that half-Life is based off Quake, and implenting the File types is just like adding MD2, Q2BSP or MD3 to it. And because HL MDL is skeleton based: Why not?

[ceriux]

You could convert any HL MDL to IQM without losing anything. I think the tools path for this already exists as well - just decompile the mdl using Valve's studiomdl tools, and export the resulting SMD(s) to IQM. Noesis can do this part, if nothing else can. Although I haven't actually tried it. I could implement HL MDL import in Noesis if this is a path people actually want to take, so that HL MDL->IQM becomes a one-step process with no manual intervention/tweaking required.

that would be amazing!

I think the only real downside to IQM is that it is not implemented in too many actual Quake engines! In fact, I believe DP is the only engine that supports it which is also meant to run Quake. Hardly seems appropriate for an "Inter-Quake Model" format.

i agree, i dont want to be forced into using one engine. also is there a model viewer for IQM?

DP also supports q3bsp

hammer/worldcraft are the easiest and nicest tools to map with. iv tried learning other tools and they are far too complex for what they need to be, making them hard to learn. we need a map format that we can compile using one of those editors. or we need an editor that works more or less the same.


actually iv been pretty disappointed with q3 content creation. i mean iv never even found a nice md3 model viewer...

[Ranger366]

YEAH, good old Quake 3 Mapping times! just bad that the editor is not very handy, like Hammer.

Ok, i know about IQM but im not the guy who takes some code (from the IQM SDK as example), and stock it to an Engine and (OMG) its fully working. if we can use IQM now, then f*cking damn implent it into Quake
And 'DarkPlaces','DarkPlaces' etc.
DP is a very GOOD engine, but its highly modified and this means that you cannot simple pick some thing of that file to this file and 'DONE'.
I cant even compile DP.

Just let me now howto work with LIT, and external textures for maps, and the HL BSP problem is solved.
I dont really need this, cause im currently not modding Quake, but i cant sleep with this rest-thing in my head.

[frag.machine]

I know that half-Life is based off Quake

Wrong.

Main differences from most Quake engines:
- Uses C++ AND OO programming (almost all Quake engines are programmed in straight C - exception made to Quake 3 - and all in a totally procedural way);
- Uses incompatible media formats for alias and BSP models;
- Uses incompatible approachs to game logic programming (find a tutorial to, let's say, add a new weapon to Quake and the equivalent Half Life code and tell me how similar they are);
- Uses incompatible network protocols.

Half Life was directly based off Quake only in its very early development stages, before being ported to C++ (I'm not even talking about alpha versions, let alone the final product).

[Ranger366]

I know that half-Life is based off Quake

Wrong.

Main differences from most Quake engines:
- Uses C++ AND OO programming (almost all Quake engines are programmed in straight C - exception made to Quake 3 - and all in a totally procedural way);
- Uses incompatible media formats for alias and BSP models;
- Uses incompatible approachs to game logic programming (find a tutorial to, let's say, add a new weapon to Quake and the equivalent Half Life code and tell me how similar they are);
- Uses incompatible network protocols.

Half Life was directly based off Quake only in its very early development stages, before being ported to C++ (I'm not even talking about alpha versions, let alone the final product).

Sry, i used the word off instead of "on".
my english isnt that good.

im a half-life modder and worked alot with the game code, i haveto say it sucks to do that, adding a Weapon is the most annoying thing.

[Urre]

hammer/worldcraft are the easiest and nicest tools to map with. iv tried learning other tools and they are far too complex for what they need to be, making them hard to learn. we need a map format that we can compile using one of those editors. or we need an editor that works more or less the same.

You can map using hammer/worldcraft perfectly fine! I've made q3bsp maps using the BSP editor many times, the racetrack in strapbomb was made this way. All you need to do is make sure that texture references in the .map file have paths in them, so you can't use the Quake .map format, but Quake2 .map format works fine, and then compile using q3map2 (use the one included in netradiant, as the "official" q3map2 hasn't been updated for 5 years or so). It's kind of convoluted, having to make .wal files of all the textures so they can be viewed in the BSP editor, but also having .tga's for q3map2 and the final result ingame, but it works for me. Thinking about it, you'd probably have even more luck when using Hammer, as it most likely supports viewing the same .tga's you'll be using for compile/game. Haven't tried this, but theoretically it should work with some hacking, probably much less than I did to get it to work with BSP.

actually iv been pretty disappointed with q3 content creation. i mean iv never even found a nice md3 model viewer...

Depends on what you mean nice, but you could try my old modelviewer, which is actually a DP mod, available on my site. Apparently some people have found it very useful, so I'm making it publicly available.

Also, just cause you use q3bsp, doesn't mean you have to use md3 at the same time. Formats supported by an engine aren't bound to eachother in any way. Strapbomb uses q3bsp for the map, q1mdl for the models and effects (there are no sprites!)

[Rich]

Man, these forums need some "highlight text in topic review and click quote button to generate a named quote for it" functionality.

i agree, i dont want to be forced into using one engine. also is there a model viewer for IQM?

Yeah, Noesis supports import+export of IQM as well. (and can directly preview anything it can import)

Ok, i know about IQM but im not the guy who takes some code (from the IQM SDK as example), and stock it to an Engine and (OMG) its fully working. if we can use IQM now, then f*cking damn implent it into Quake

I don't think there's been a very active push for IQM integration in actual Quake engines. People who maintain engines just need to implement it in their own engines so that it starts to catch on. It's not a flawless spec, but I'd say it's the best option available between the existing skeletal formats in DP. And it's a format that, judging by the name, was intended to be shared across Quake engines.

And 'DarkPlaces','DarkPlaces' etc.
DP is a very GOOD engine, but its highly modified and this means that you cannot simple pick some thing of that file to this file and 'DONE'.

I'm not at all sure what you're trying to say here. Are you saying you can't convert files easily to supported DP formats? Or that you can't easily merge code from other engines into it? I guess the latter seems more likely, but since it already supports IQM, I'm not sure what you'd actually want to be implementing in the engine side.

Wrong.

Wrong. HL is based on Quake quite fully, and the only difference between a HL BSP and a Quake BSP is a version change from 29 to 30, 3 lightmap channels, and texture lumps that can contain palette data. That's just going from memory, but assuming I'm not forgetting anything, the rest of the format is 100% identical. Therefore it's quite fair to say it's very heavily based on Q1's BSP format.

You can also simply disassemble the initial retail Half-Life exe and find tons of pretty much identical routines, including the majority of their BSP traversal and other related code. While you can hardly compare the HL game code to the Q1 QuakeC, the engine-side changes were evidently not so drastic. They did, in the end, add more than I tend to give them credit for, but a large portion of it didn't even come until after their initial shipping to retail.

So it's fair to say that HL was, as of shipping, still based very heavily on Q1 from a code standpoint, and from a data standpoint, given how barely-removed their core BSP format is from Quake's.

[andrewj]

HL is based on Quake quite fully, and the only difference between a HL BSP and a Quake BSP is a version change from 29 to 30, 3 lightmap channels, and texture lumps that can contain palette data.

The HL BSP also uses plane pairs as in Quake2, and uses the fourth hull for crouching. Plus a few minor changes: different bboxes for the clip-hulls and a few limits are higher (e.g. size of entities lump).

[Rich]

The HL BSP also uses plane pairs as in Quake2, and uses the fourth hull for crouching. Plus a few minor changes: different bboxes for the clip-hulls and a few limits are higher (e.g. size of entities lump).

Yeah, I'd actually noticed the plane pairs while I was reversing the formats. But I wouldn't call it a real format change, because the indexing into the planes list is adjusted appropriately. So you just have a bunch of extra planes lying around in case you want to actually use them.

The other stuff, I'd have to take your word for. I never bothered to reverse clipping/hull data for my Q1/HL/Q3 loaders. (and I've never even actually looked at Q2's BSP format) Though I do preserve (and translate) tree+vis+light data on export in Noesis, for formats which can actually support it.

[frag.machine]

Wrong.

Wrong. HL is based on Quake quite fully, and the only difference between a HL BSP and a Quake BSP is a version change from 29 to 30, 3 lightmap channels, and texture lumps that can contain palette data. That's just going from memory, but assuming I'm not forgetting anything, the rest of the format is 100% identical. Therefore it's quite fair to say it's very heavily based on Q1's BSP format.

The basic structure, yes; but the number of changes are far higher than a simple bump in the BSP version can suggest. For example, the number of contenttypes are far higher, and this means much more server side code to deal with. It supports transparent / stippled textures in the worldmodel, which is not exactly that simple. Also, if IIRC the PHS from Quake 2 was also added, which alone implies a good ammount of rewrite in the sound subsystem. And let's not forget the 4th collision hull, which to be fair can be quite easy to add.

The fact is, to make a Quake engine correctly support a full featured HL BSP demands a lot more of work than you cited. One can easily add partial support like in Baker's tutorial, but a number of things that can be important for some maps will be missed.

You can also simply disassemble the initial retail Half-Life exe and find tons of pretty much identical routines, including the majority of their BSP traversal and other related code. While you can hardly compare the HL game code to the Q1 QuakeC, the engine-side changes were evidently not so drastic. They did, in the end, add more than I tend to give them credit for, but a large portion of it didn't even come until after their initial shipping to retail.

Let's say that IF I had the chance to check the leaked source code on that awful hacking incident years ago (not that this actually happened, mind you ) I could say to you that the engine was rewritten in C++ using OO (that's an important thing to note), and thus would keep little resemblance (if any) with the original code. Of course, the resulting binary would be very similar to the C counterpart. But the source would be very different, to the point that backporting something from this engine to Quake would demand as much effort as doing everything from scratch.

So it's fair to say that HL was, as of shipping, still based very heavily on Q1 from a code standpoint, and from a data standpoint, given how barely-removed their core BSP format is from Quake's.

The same can be said about Quake and, let's say, Quake 3. And yet, they are different enough to turn the backporting of many features (which is the point I am discussing here) a questionable task.

[Rich]

Though it's not actually very related to HL being based on Quake, I maintain that supporting HL BSP in a Q1 engine is a completely trivial task, because most of the core data structures are identical. The only structures I'm not directly familiar with are the ones used exclusively for hull/clipping data, and from the sound of it, nothing there has changed significantly either. In terms of things HL does that aren't related to the actual BSP file structure, this has very little to do with the fact that the file format itself is directly based on Quake's, with very few actual variations.

Within the context of the format itself, we are not even talking about the addition of complex features here. We're talking about completely trivial changes - which is why the Quake engine can be made to handle HL BSP's (in terms of actual format features) by following a simple tutorial. This tutorial doesn't need to include new routines to traverse the tree or interpret visibility data. Why? Because it's the same!

Well, I didn't look at the source leak, but if they had changed anything significant in terms of encapsulating BSP-related code, it would be clearly visible in the disassembly with, at the very least, some differences in stack or absolute data address offsets. In HL 1.0.1.0 (retail, pre-Steam) the routines are *exactly* the same and use *exactly* the same internal data structures.

It's pretty dumb to say something isn't based on something else, just because someone crammed some existing code into some encapsulation structures. Also, you know, you're using C in an "object-oriented" manner when you're using structs to define your data. Shoving routines and structs inside a pointless class encapsulation layer doesn't make it any more or less object-oriented. Neither does renaming your modules from .c to .cpp. If you're this happy-go-lucky to dismiss something as no longer being derivative in code, I certainly hope you never find yourself in a situation where you need to "rewrite" a codebase to distribute it under a different license!

You also told Ranger366 he was "wrong" for saying HL is "based off" Quake, and then said "Half Life was directly based off Quake only in its very early development stages." This is just clearly and completely wrong no matter how you look at it. You can crap all over a chocolate cake, but there's still going to be a chocolate cake underneath all the crap. And if you try to sell it as a crap cake, you can't just say you made the cake all by yourself. You took a cake, and then you took a crap on it. It's a derivative product. In the specific case of the BSP format itself, you can't even say there's a hefty layer of crap on top. At best, it has some tiny turd bits sprinkled over the frosting.

It's still using the same internal data structures. In many cases, the same core routines. What is your motivation in saying HL isn't based on Quake? I would say you must have some bizarre personal motivation here, as I don't see why else you'd embrace such an easily-disprovable notion. I kinda feel retarded for even indulging this argument.

[frag.machine]

I guess we are deviating a bit from the real point of the discussion. I never said it was impossible to support HL BSP in Quake; it's already done (in a partial way) by Baker and others in a number of engines. The point here is: a) it's a partial support, and doing a full implementation is not that trivial (But I concede that "not that trivial" is a very subjective concept; what requires a lot of work and thought to me can be trivial to you or other experienced engine coders) and b) what Ranger366 and others really want is full support to all Half Life features (not only BSP files, but models and everything else, kitchen sink included - in other words, they want the Half Life engine, not Quake) into a PSP port, and they want this arguing that "Half Life is based on Quake, so this must be easy to do", which is a completely WRONG reasoning. And that's why I suggested to him in another similar thread that instead insisting in this approach, they should start a movement to press Valve in order to release their now 12 year-old Half Life engine under an OSS license so someone can at least try to achieve what they want from the right start point. Personally, I'd love to have a chance to study how they implemented a lot of things in a legal way.

And about your scatological analogy: at least to me, crap over a chocolate cake always turns the whole into crap, regardless if it's only a tiny piece of crap. But hey, there's always people who are less demanding...