MD3 support for Fitzquake and Quakespasm!? :)
I for one can use this already... I'm using it to replace models for KMquake2 and currently working on a new Shambler model for the Original Quake. But ofcourse it ends up as an MDL in Quakespasm and Fitzquake... My pipeline goes from 3dsmax exported to FBX and then I simply use Neosis for the conversion to MDL right now. Works perfectly but the model formats lack of precision makes me sad. If somebody adds MD3 support I could pretty much instantly take advantage of it. I would still use the quake palette though because I prefer the pixel retro look.

IF you add it I will use it! Regardless

https://www.dropbox.com/s/ckylp58vipdh9e3/Shambler_Wip.jpg?dl=0

Here is a sneak preview for those wondering what it looks like. 

https://dl.dropboxusercontent.com/u/1849053/Shambler_Wip.jpg 

i've seen vertex dancing on md3 though... it's a lot less, but it's still there. is there no better format? 

what about something similar to external textures...
so you have your player.mdl
and then you have player_0.fbx, player_1.fbx, etc... and give external model information.

the workflow these days is to export multiple single frames and use tools to merge them into a .mdl anyway, so for the modeller, it's not adding any steps anyway. 

mwh:I think the point is more that observing that this is a problem does not bring us any closer to a solution.

I just want to prevent myself from writing bad code in the future (and I hope I have the definition correct and complete). And needed to know what "bad code" looks like --- bad code isn't obvious.

That is all I can do.

sleepwalkr:So, I for one don't believe that there will ever be a system that will write your code for you.

Is anyone actually writing any complex code to begin with? I don't know that ..

1) Anyone is.
2) If it is even possible to do so.

You've put tons of work into Trenchbroom, but isn't it all rendering triangles by distance at the end of a frame, when everything is said and done?

Developers: creators of simple works, using crude tools. Rewarded with praise for winning the endurance and stamina test using crude tools that are hard to understand, use correctly and master. The idea conceived in seconds, the debugging achieved in hours, but the implementation --- should it ever come --- will take months, if ever at all.

However, if you master a low-level language like C, you can do almost anything without any natural limitations except time. Knowing time is the limitation, I want to re-evaluate my use of it.

I do know the definition of insanity is doing the same thing over and over and expecting a different result.

I think this sums up current thoughts on the subject quite well: http://forums.inside3d.com/viewtopic.php?f=1&t=1283&start=2

I debated on clicking 'Submit'. Logic says no. The Labatt's Blue says "apathy now". And who am I to question the logic of beer! 

Just a quick reply then:

You've put tons of work into Trenchbroom, but isn't it all rendering triangles by distance at the end of a frame, when everything is said and done?

Not by a long shot. 

bad code isn't obvious.

I take offense to that. Mine certainly is. 

Currently we can choose between linear filtering and nearest-neighbor filtering. How about giving hqx a try? 

The filtering that is currently available is there because the hardware supports it, hqx would probably have to be done by up sampling the textures in software and loading the higher res images to the video card. Which you could also do manually using external textures. 

Question is would hqx even look good on quake textures, since it's designed for pixel art 

Yeah hqx only looks half-decent on stuff like nes sprites - In Quake it would just look like you've upscaled the texture then run them through some ugly watercolour filter or something. 

I looked into other texture filtering once and it is not worth it unless you are into amateur painter art. 

No idea what I used to create them but here is scale4x: https://transfer.sh/Liu3e/scale4x.7z 

 

new super8 release: http://super8.qbism.com/2015/02/build-2-bsp2-map-support-and-transparency/

bsp2 and 2bsp thanks to quakespasm source for guidance
http://super8.qbism.com/wp-content/uploads/2015/01/qbs8_017.gif 

awesome, always good to see bsp2 on a wider range of engines! 

also, that RRP video revealed to me a design flaw in the burning player effect from rubicon 2 -- if your health is > 100, you can't pick up a health pack, which means you can't stop the burning! 

Especially that MadFox map for RRP looks good. 

It really is fun to play Quake on, and it's often overlooked (I have to remind myself it exists occasionally). What I really love is low-grav + gore. This makes Quake even gorier :)

Here's some gore screens from my low grav map (coming soon I hope) -

https://www.dropbox.com/s/vfu25hshcyv71s2/qbs8_003.png?dl=0
https://www.dropbox.com/s/p6ar35jwz14y9p1/qbs8_004.png?dl=0
https://www.dropbox.com/s/9cdnkifemxz2tld/qbs8_005.png?dl=0
https://www.dropbox.com/s/pyedcf3wwqqa453/qbs8_006.png?dl=0 

super8 - pretty cool, but when fog and coloured lighting is all going on, you tend to lose a lot when you try and map that back to the quake palette. 

Super8 - played in it for five minutes - could kinda do with "make it look/sound like quake" preset in the options :)

Over-the-top weapon bobbing craziness...quake's 8-bit sounds up-sampled to whatever...starts with a funky palette bend by default...not my cup of chai I'm afraid :) 

I wish you guys realised how bloody annoying Dropbox is. Every time I click a link here, I get a popup if I want to join it. 

 

Uhh, is the new bobbing combined with the regular bobbing? It looks like the weapon is twitching in all directions at once. 

you have to join it
It is simple as that