What are you working on?

[ceriux]

sock, its for a fantasy themed mod. supposed to be dwarven / obsidian. but not for quake.

[sock]

supposed to be dwarven / obsidian. but not for quake.

IMHO the colours are wrong. When I saw your hammer I thought of this. When I imagine a Dwarven hammer I think of this. The colours you have choosen dark blue/gold (especially quake palette) seem odd, try silver/gold, grey/brown. Also the top frame (the yellow bit) does not look dwarven magical, it feels like a modern day industrial metal frame.

[leileilol]

[frag.machine]

New Tesla Coil model (WIP, unskinned):

I suppose it depends on what type of theme you are going with, modern/futuristic Q2 or old world Quake. I thought it was a Q2 weapon when I first saw it. If this is the theme you want then it looks cool but it could be better if it fit with the Quake universe instead. Maybe add older elements to the shape?

Maybe add Old Radio Valves considering your project source it would be ironic

Always thought the telsa gun from Wolfenstein was cool looking because it felt old tech.
http://www.youtube.com/watch?v=r3HCYBRtibs

EDIT: Fixed URLs

Thanks for the tips, sock. Not trying to follow the Q2 path here; and in my vision Quake weapons should remember something low/old tech (vintage ? steampunk ? maybe a mix ?), possibly dropped by a defeated monster, hence the bruises and rust everywhere.
I considered placing some wires, but they didn't look very good in a low poly model; electronic tubes could be a very good idea actually, but TBH I am happy with this... It remembers me a love child between the HL2 gravity gun and the Q3:A lightning gun.

I finished the skinning part, working now in the animations:

[frag.machine]

supposed to be dwarven / obsidian. but not for quake.

IMHO the colours are wrong. When I saw your hammer I thought of this. When I imagine a Dwarven hammer I think of this. The colours you have choosen dark blue/gold (especially quake palette) seem odd, try silver/gold, grey/brown. Also the top frame (the yellow bit) does not look dwarven magical, it feels like a modern day industrial metal frame.

Would be cool if the yellow part were some sort of metalic claw holding the rock. When I looked at this at fist I thought it was Dr. Freeman's sledgehammer

[qbism]

Best use of this algorithm I've seen. How is the fps affected vs undithered sprites?

[ceriux]

sock i agree with your dwarf style concepts. but i sorta wanted to see how well using my own ideas of what a dwarf might be. i sorta thought like this dwarf>mines>tech>hammer.

i dont know and i didnt want my hammer to seem too much like a wow hammer? which is more what that hammer you posted feels like to me. i was thinking because they're always in the mountains they'd be sorta semi-civilized yet still semi-barbaric. so i was thinking more of a hammer similar too this, but with more of a light steam punk feel.
(their dwarven harpoon is a spear with dynamite strapped to it)



the mod this is for though is hard to pin point a style that would match it best. because it has such a small development team, they take what ever content they can get.

examples:

http://media.moddb.com/cache/images/mod ... _alpha.jpg

http://media.moddb.com/cache/images/mod ... /68067.jpg

http://imageflock.com/img/1316906002.png

http://imageflock.com/img/1317946579.png

either way it cant be bad to try another style/type.

[leileilol]

Best use of this algorithm I've seen. How is the fps affected vs undithered sprites?

A little less when comparing unfiltered additive and filtered additive. The sprite spans could also use some duff device'ing as well, as it's extremely similar to the brush drawspans

[taniwha]

ceriux: I think the only problem I have with the hammer is the edges of the metal (near the top) seem a tad sharp. A little bit of uneven "rounding" would give the hammer that hand-forged look. But then, if your dwarfs have mills, anything goes .

[Seven]

I am sorry to interupt. I just wanted to tell taniwha that the spider is now available for download.
You said, that you might be interested in it, when we talked about it some time ago in this thread.
http://quakeone.com/forums/quake-mod-re ... thers.html
Sorry that it took longer than expected. well, you know these things...
Freetime is getting more and more critical rare.

Cool to see all the fantastic new stuff on the last pages in this thread.
You guys are amazing !

[Dr. Shadowborg]

I am sorry to interupt. I just wanted to tell taniwha that the spider is now available for download.
You said, that you might be interested in it, when we talked about it some time ago in this thread.
http://quakeone.com/forums/quake-mod-re ... thers.html
Sorry that it took longer than expected. well, you know these things...

Looks cool, but isn't 60mb a little...extreme sizewise?

Also, does this include the QC source?

[taniwha]

Seven: awesome! As for free time... yeah, it's always hard to come by enough of it.

I guess I have to give QF .pk3 support

*sigh* more work

[revelator]

your welcome to rip pk3 support from my realm engine if you want it builds with mingw out of the box so in that regard it should be easy to convert for your use.
it loads compressed pk3 as well but the code for loading demos needs a little work as it cant load them from pk3 yet, everything else works though.

[mh]

PK3 support is easy to rip from Q3A as well. For demos (or any other file type that needs to be incrementally read rather than taking the entire file in one go) the easiest way I found was to unpack it to a temp file (which will be uncompressed) and read from that. If your filesystem API of choice has a "delete-on-close" flag available then everything becomes really easy. If it doesn't - well, you need to clean up manually when done.

[taniwha]

reckless: mh: thanks for the tips.

As for demos in compressed pk3: I doubt they're that different from compressed demos in .pak (using gzip (zlib)*, a feature QF has had since about March 2000 (minus a few months where knghtbrd got pissy)).

Initially, the compression was indeed a liability (demos slowed down exponentially(?) as they progressed), but the problem was not the incremental reads, but rather the reverse seeks used for keeping track of when the next packet should be read. I modified the demo reading code to cache the packet time value and never seek: suddenly compressed demos were faster than uncompressed demos

[* this is why menu.dat is packaged as menu.dat.gz: QF automatically appends .gz when searching, and checks the file header for gzip-ness when opening: the rest of the system knows nothing]