OMG IM MAKING A HD TREMULOUS ALL READY.
Want to help?
We all ready got most of the maps in HD and were pushing up the vertices in all the models to make it more poly.
Were working on the codes to make it HD also.
Were working on Codes, Models, and Graphics.
Also new HUD as well.
Were working on the codes to make it HD also.Hahahaha, HD code?
Oookkkaayyy. I see epic shit here.Were working on the codes to make it HD also.Hahahaha, HD code?
Wasn't there some new rule on trolls?Mostly the cold, ugly ones.
I think it looks oversaturated and the contrast's a bit much, but i'd need a good quality standard goon render to compare to, really.That's true, a comparison picture would be nice.
that's it, what do you think ?
The textures are tiny. You guys make me laugh, HD renders of low quality objects. We need quality objects!
I've thought about enlarging the current textures for the aliens then brushing them over with some procedural textures and images to make them look better.
the legs have "segments" like the tyrants crown. make the segments go into the goon a little moreSadly, as google translate doesn't provide a swamp-cecil option, i'll have to ask you to explain what you're on about.
That's antiailising issue(I know it's being spelled wrong).You what? Who's pointing out problems with aliasing?
You can tell trem to do some of that work and then for some people your GPU to make it even cleaner
[img]
Before is on the left.
After is on the right.
And we didn't even do all the effects yet.
Looks good harraps though.
+1
Lonly, I really like your texturesCan you explain why, so that i may like them too?
I have sod-all idea what i'm doing, but hey, doesn't that noise look nice.
(http://i.imgur.com/K5QYU.jpg)
Lonly, I really like your textures but I've got 2 questions.
Why don't you use the Xreal engine if your are making a HD tremulous?
You're saying you increase the polycount and the texture size, but why don't you use heightmap or normalmap and md5 models.
Those things don't need a lot of work to make.
Erm, how i did what? Do you think i removed the noise? Left's before, right's after, i added it, to give the false impression of extra detail at higher resolutions.I have sod-all idea what i'm doing, but hey, doesn't that noise look nice.
(http://i.imgur.com/K5QYU.jpg)
Doing Noise Reduction...
Mind telling me how you did that?
HD Rifle (Without Noise) and HD Flash...You don't make the graphics for a whole game using filters. Fact.
[img]
I took the one Tremulant gave me and applied Color Vibrant.
(http://img34.imageshack.us/img34/5687/beforeaftert.jpg)is wasted?
Oh, but lonly, does that mean that all the hard work you did on:He supposedly did some original models for the [FuN] mod, but I still haven't seen it. I smell vaporware.[img]is wasted?
You're supposedly a pr0 modder who's about to start an xreal port of trem and yet you decided to take my amateurish attempt and fuck it up further, rather than doing something original with your leet skills? Curious.
Come on people, if you can't even manage to produce something less half-arsed than my attempt, don't bother...
I don't have Adobe Photoshop, I've been using Gimp.Same here, thanks for the PM, lonly, btw.
I don't have Adobe Photoshop, I've been using Gimp.Same here, thanks for the PM, lonly, btw.
No, i don't particularly feel like doing the same for the shotgun for you, but i will tell you roughly what i did.
Open original texture, scale to 400%, apply gegl's bilinear filtering(you'd probably get better results with g'mic's anisotropic noise reduction but i couldn't be bothered to install it on this box at the time), add correlated rgb noise to a sensible level.
Votre travail est tout simplement remarquable ! (Google translation: "Your work is simply outstanding !")I see no "work" on that thread, only demonstrations of features that are already available in most modern games. I'm filing this under "vaporware".
The only thing that scares me about xreal porting is getting the physics of the game.What? XreaL has the same physics as Q3(which Tremulous is based off of). It's the same game engine as ioquake3, with a re-written renderer.
What I mean by the physics is the gameplay because from what I can understand Xreal uses MD3's(our current assets as place holders) and when you have stuff that already works we can upgrade them later.You're confusing like 5 different things here.
Xreal uses Md5 and mtf formats for shaders.*mtr
It'll be funny when these HD trems are about to be released and 1.2 shows up.Not if one of them comes out before Thursday.
'High Definition' is marketing bullshit. As has been noted already, its only real technical meaning has to do with display resolution. When used as a descriptor in any other context it's meaningless (do commercials for 'HD audio' bother anyone else?).+1 for this. Tremulous already has HD, in fact, it works with any resolution if you use the custom mode.
Frankly, if you want a higher quality render output, it's not so much the models that need to be changed. Rendering lots of polys is still hard and a waste of time. The client engine really needs to be written to include some form of modern bump mapping (http://en.wikipedia.org/wiki/Bump_mapping) such as parallax (http://en.wikipedia.org/wiki/Parallax_mapping) or normal (http://en.wikipedia.org/wiki/Normal_mapping) mapping so that more complicated geometry can be simulated without significant increases on hardware requirements. Displacement (http://en.wikipedia.org/wiki/Displacement_mapping) mapping would be really nice. Solving graphics ugliness by increasing game model detail is the brute force method and isn't really as effective as other, cheaper (in terms of hardware load) solutions.
Also, none of these improvements are going to look really good unless and until we get dynamic lighting and soft shadows.
'High Definition' is marketing bullshit. As has been noted already, its only real technical meaning has to do with display resolution. When used as a descriptor in any other context it's meaningless (do commercials for 'HD audio' bother anyone else?).
But just like directly contradicting an engineer's philosophy(in some ways, sorta..) we can have a higher polycount and get great FPS with machines that have a $50+ GPU. Efficient? No. Works well within reason? Yes to a decent to good degree.So what you're saying is you want higher-polycount models, and that this has nothing to do with a "HD tremulous".
under HD tremulous you mean just bigger and more detailed textures or what? If you want make 'better' trem with improved visual style and animations 1st remake client side and implement new rendering engine, for example xreal.So changing the rendering engine will magically make the textures more detailed? A new engine can only do so much, and while it would be nice, treating an XReal port like some sort of silver bullet will get you nowhere. Good engine + shitty textures = shitty graphics. Since modern game graphics place emphasis on a low polycount, almost all the detail is in the textures.
So 1st - upgrade engine, 2nd - improve textures/shaders accordingly to new engine and only in 3rd talk about 'ultimate HD version' of tremulous.Surprisingly I agree with this. +1 for you.
we won't have to worry about new textures because people will gain an interest in helping trem and see the ugly bottleneck of crap textures.Oh, that's ok then.
That "quirk" is called octree mapping. Sauerbraten uses a completely different map format- maps are made completely of huge arrays of cubes, where the vertices can be pushed and pulled to make non-blocky shapes. The maps can be really high-quality stuff (check out Skycastle, that thing is EPIC), but it's a completely different format.
If we can get the mesh into it without it being some giant mess then texturing and doing materials should be easy.
Well unless the mapping software(whatever it is) has some quirk.
Soon grandma will own a quadcore, you'll own a 16 core CPU, and GPU rendering will be norm.Why this obsession with the future of computing? What matters is what's affordable and current, i don't care about your granny and her quadcore box.
Admit it, you can't help but admire her l33tness.Soon grandma will own a quadcore, you'll own a 16 core CPU, and GPU rendering will be norm.Why this obsession with the future of computing? What matters is what's affordable and current, i don't care about your granny and her quadcore box.
+1 8)Admit it, you can't help but admire her l33tness.Soon grandma will own a quadcore, you'll own a 16 core CPU, and GPU rendering will be norm.Why this obsession with the future of computing? What matters is what's affordable and current, i don't care about your granny and her quadcore box.
No obsession. The reality is that it's not a bad idea to port trem to a demanding engine if in a year or two it's requirements won't be that much.
1.2 is as we can currently judge a gameplay and graphical upgrade that involves manipulating the current assets,
and from what I can understand they are not touching the current engine's code.
Plus they(from what I understand) are not going to touch textures, upgrade models,
well minus the new weapons and the new human model.
None of this stuff is easy but it would be rewarding to port or more realistically upgrade the current assets,
if we upgrade the current assets we can squeeze the engine with some brute force.
About the off comment that magically dumping Trem into XReaL won't improve texture detail:
IOQuake3 appears to use software mipmapping as respect to archaic hardware that wasn't compatible. This makes the textures appear 2 times as blurry as they actually are, especially at a distance. It's not really a big difference, and could probably be implemented into trem without much issue, but I felt it was worth mentioning anyway.
@Fox One
I disagree, shaders such as parallax/displacement have a far more significant impact on framerate, compared to brute-force polygons. The majority of Tremulous' theme is 'tech', that includes metal base matt textures, metallic trims and the like. These shaders weren't made with that purpose in mind, which is why they apply far better to games like Crysis and FarCry, where running shaders on masses of terrain is of course cheaper than ridiculously high polygon counts.
Not true,Well currently it is a bottle neck.
It would most likely be trivial for someone experienced with GL to patch in hardware mipmapping (assuming such a patch doesn't already exist). Mipmapping isn't really something to change engine for, and it certainly does not inhibit or 'bottle neck' textures in any way.
How many times do I have to say this? A port to XreaL would not require new assets. It would look no different, but it would use code that is designed to run as much graphics on the GPU as possible, speeding up the game vastly. The enhanced material effects and special model formats can be utilized later.
Well some of what yon stated(q3acompat flag) I do not fully understand although I do know what GLSL is and it's sweet, I've toyed with it within blender's BGE.How many times do I have to say this? A port to XreaL would not require new assets. It would look no different, but it would use code that is designed to run as much graphics on the GPU as possible, speeding up the game vastly. The enhanced material effects and special model formats can be utilized later.
Because compiling XReaL with the q3acompat flag enabled does not allow it to run on pre-GLSL (6200) hardware. Hence the argument of 'Switch to XReaL - Faster FPS - New Hardware Only!" doesn't make much sense.
You really think that half of current tremulous players have so old PCs?I think a poll might be in order.
You really think that half of current tremulous players have so old PCs?I think a poll might be in order.
In this day and age, there's really no reason to hold on to hardware pre Geforce 6xxx series. I really think it would be better for everyone if we dropped this mentality of 'doesn't run on old hardware so it is automatically shunned'.How many times do I have to say this? A port to XreaL would not require new assets. It would look no different, but it would use code that is designed to run as much graphics on the GPU as possible, speeding up the game vastly. The enhanced material effects and special model formats can be utilized later.
Because compiling XReaL with the q3acompat flag enabled does not allow it to run on pre-GLSL (6200) hardware. Hence the argument of 'Switch to XReaL - Faster FPS - New Hardware Only!" doesn't make much sense.
Well if it looked identical then it wouldn't :)Turn off HDR or other post-processing and it will.
1.1 is ported, and they just added bloom and some other effects for the moment, nothing over the topWhat? It has all the features of XreaL, including but not limited to bloom.
Doesn't lighting need to be redone for every existing map?Not necessarily, if you are thinking that all maps need to be recompiled. I believe the 1.1.0 port can be compiled with compatq3 mode.
Doesn't lighting need to be redone for every existing map?Map recompilation its not so hard work. Even without map source (using .bsp decompilation) you can redone map per day ezily.
I'm only basing this assumption on what thorn's told me in the past.Doesn't lighting need to be redone for every existing map?Not necessarily, if you are thinking that all maps need to be recompiled. I believe the 1.1.0 port can be compiled with compatq3 mode.
Wait, slow down a second. Recompiling maps, if they don't require any manual work, sounds like it should be something you can do with scripts. That makes it a lot easier.
Doesn't lighting need to be redone for every existing map?I'm only basing this assumption on what thorn's told me in the past.
Not necessarily, if you are thinking that all maps need to be recompiled. I believe the 1.1.0 port can be compiled with compatq3 mode.
The material keyword(diffuseMap, normalMap, etc) support can be just re-enabled after the fact. I think it's switched off with a simple #ifdef.Doesn't lighting need to be redone for every existing map?I'm only basing this assumption on what thorn's told me in the past.
Not necessarily, if you are thinking that all maps need to be recompiled. I believe the 1.1.0 port can be compiled with compatq3 mode.
Yes, tremulous should be compatible if you compile XreaL with q3acompat, but this does mean not getting any of the features from XReaL's renderer, and at the end of the day it seems a bit pointless. I did mention this before to you, and why it was a bit pointless since the only benefit would be the framerate, and even that can be nullified by the fact that it requires hardware well capable of running the game anyway.
That would probably just be a small project then, compiling the XReaL client in q3acompat with tremulous support, which could likely be distributed as just another optional binary client. Of course, that's purely assumption.
Yo. I'm in that kind of mood again and so decided to do some concept work for a higher detail goon. My suggestion is that higher details beg for a new more interesting texture. Let me know if you like the direction I've taken and should continue it!I do indeed like it, except for the odd purple spots in the middle of the leg.
[img]
Im not coder, but seems its fact or something.
Wut for this quote? You agree with this, disagree or forcing me ask our mod coder for details? =DIm not coder, but seems its fact or something.
If you only want to add some noise to the textures to make them less boring at close views, you can use detail textures, i.e. you use the mid-res textures that you have now and add a noise texture in a second renderer pass. The noise texture can be repeated over the surface, so it does not need to be big for high resolution.
If you only want to add some noise to the textures to make them less boring at close views, you can use detail textures, i.e. you use the mid-res textures that you have now and add a noise texture in a second renderer pass. The noise texture can be repeated over the surface, so it does not need to be big for high resolution.Is this the kind of thing that was going on in serious sam when the camera got up close to an object? It did quite a good job on stone textures and the like.
Is this the kind of thing that was going on in serious sam when the camera got up close to an object? It did quite a good job on stone textures and the like.
textures/utcs/eq2_bmtl_02
{
{
map textures/utcs/eq2_bmtl_02.jpg
}
{
map $lightmap
tcgen lightmap
blendfunc filter
}
{
detail
map textures/utcs/detail.jpg
tcmod scale 9 9
blendfunc GL_DST_COLOR GL_ONE
rgbGen const ( 0.66 0.66 0.66 )
}
}
Yo. I'm in that kind of mood again and so decided to do some concept work for a higher detail goon. My suggestion is that higher details beg for a new more interesting texture. Let me know if you like the direction I've taken and should continue it!
(http://img9.imageshack.us/img9/4748/dragoonnewleg.png)
This is not HD graphic but it is ATCS map in better HD capable engine (Unreal Engine 3). Map is 99% finished, some energy fence and skybox missing yet. I rebuilded it piece by piece. Textures are ugly ATCS default without any effects.
(http://img33.imageshack.us/img33/8471/59991917.jpg)
cool, better shadows are one of the things trem needs...derp
Example screenshot: (http://lh6.ggpht.com/_hLklTmrBczA/TPAjBbN4XQI/AAAAAAAAADc/y9Z3wFyeI3s/s800/shot0008.jpg)This seems to have some potential.
This shows a small 128x128 noise texture with horizontal blur that I made in 2 minutes added to the left texture. The shader scales the detail texture by a factor of 9, so that it has an effective resolution of 1152x1152 pixels
This is not HD graphic but it is ATCS map in better HD capable engine (Unreal Engine 3). Map is 99% finished, some energy fence and skybox missing yet. I rebuilded it piece by piece. Textures are ugly ATCS default without any effects.
I didn't know you can run quake 3 mod on Unreal engine 3 ?!
Unreal Engine is really cool but can you give us it for free ? That's the question.
It's really cool BUT ... you didn't use bump maps.
Anyway that's awesome and it's a good beginning full of sucess.
Unless its free, UE3 is a waste of time, even if it makes you computer shit lollipops.His point is that Tremulous looks better on other engines.
So, rotacak, since everyone wants the xreal port for better FPS on modern hardware(well, not everyone but a number of this lot), how does your framerate compare between the UE3 trem clone and standard trem at the same res, is it a dramatic improvement?Well, everyone want xreal port because it is "easy" and multiplatform. But how I see, xreal have no physics engine and would be nice to have some new features with new engine than only graphic - like destructive enviroment, clothes, vehicles, physics buildables (you can throw barrel on dretch and crush him etc.). And xreal community is very small (look at their forum), same with new releases.
Comparing framerate will be difficult because it depends on map.
Unless its free, UE3 is a waste of time, even if it makes you computer shit lollipops.His point is that Tremulous looks better on other engines.
If you want, I'll see if I can make some normal maps for ATCS textures. Then we can see how it would look with bump-mapping.
1) I know.Can I give you an advice?Unless its free, UE3 is a waste of time, even if it makes you computer shit lollipops.His point is that Tremulous looks better on other engines.
If you want, I'll see if I can make some normal maps for ATCS textures. Then we can see how it would look with bump-mapping.
Try to use original texture and turn them in black and white and then in normal maps with the gimp
But that will be Q3 vs U3, not xreal VS U3.Comparing framerate will be difficult because it depends on map.
Go ahead and use ATCS for the comparison...
But that will be Q3 vs U3, not xreal VS U3.That's quite alright, it's a test of a modern 3D engine versus the antiquated ioq3, choking on its various bottlenecks, we don't need a direct comparison with xreal here, afterall the main reason people seem to want a quick and dirty port to xreal is for the much needed potential performance gain on those machines with modern graphics cards(this may not make much sense but hey).
cataha, are you seeing much difference at this stage, quality wise?Yes, even in editor:
I rebuilded it piece by piece. Textures are ugly ATCS default without any effects.Look at model shadows. In Q3/Trem we have no proper shadows from models. Actually we cant compare those two engines properly, they base and possibilities too different.
(http://img257.imageshack.us/img257/9544/65268520.jpg)
But hadn't the zomg xreal crowd already decided that a port to xreal would give a massive performance boost from simply taking advantage of modern gpu features? surely UE3 will have a similar base advantage before it starts wasting time on pretty effects that we can't really see?That reminds me, what about Sauerbraten? A port would take forever, but I'd really want to see an ATCS-versus-ATCS comparison for Sauer.
But hadn't the zomg xreal crowd already decided that a port to xreal would give a massive performance boost from simply taking advantage of modern gpu features? surely UE3 will have a similar base advantage before it starts wasting time on pretty effects that we can't really see?So we taling about U3 vs Q3 or about XReal vs Q3? If about XReal vs Q3, then obviously XReal pwn. But dont compare XReal with U3, because U3 more wide-purpose engine, than Xreal, which was created especially for Quake-like shooter. It have no those unnecessary features, that we dont need in trem (face animation, special plants/trees processing, cloth animation, etc)
But hadn't the zomg xreal crowd already decided that a port to xreal would give a massive performance boost from simply taking advantage of modern gpu features? surely UE3 will have a similar base advantage before it starts wasting time on pretty effects that we can't really see?So we taling about U3 vs Q3 or about XReal vs Q3? If about XReal vs Q3, then obviously XReal pwn. But dont compare XReal with U3, because U3 more wide-purpose engine, than Xreal, which was created especially for Quake-like shooter. It have no those unnecessary features, that we dont need in trem (face animation, special plants/trees processing, cloth animation, etc)
But hadn't the zomg xreal crowd already decided that a port to xreal would give a massive performance boost from simply taking advantage of modern gpu features? surely UE3 will have a similar base advantage before it starts wasting time on pretty effects that we can't really see?That reminds me, what about Sauerbraten? A port would take forever, but I'd really want to see an ATCS-versus-ATCS comparison for Sauer.
EDIT: rotacak, how are you getting 600? Isn't there a maximum framerate in Tremulous, and if there is, how do you disable it?
The biggest issue is this.
Porting is a pain, and getting Trem to XReal is a hard thing to do for people who have a life and a job.
Take something that would need a total recode such as U3 and the chance of porting plummets to almost nothing.
Every few months there's a thread just like this, which makes me somewhat hoping for an XreaL port of Trem. Every one of these threads ends disappointingly with nothing.
Until someone(with actual knowledge in how this stuff works) does something to make that a reality, you're wasting your time.
If you want, I'll see if I can make some normal maps for ATCS textures. Then we can see how it would look with bump-mapping.Make some then, I want to see it too :)
Apart from the development aspect I think a new engine at this time will split the already small community of Tremulous players again. Some think that after 1.2 is released all the 1.1 players/server will migrate to 1.2, but I'm not so sure. If you now add a new engine with new models/maps etc, this means that you will also have servers for the new maps and servers for the old maps and players need the right client for the right server.Not only split, but expand too and attract new players. For expample many old trem players in russian community switching to Natural Selection 2, and its just because of outdated Trem engine. Im sure that while 1.1 master server is up there gonna be players in 1.1 (im one of them). Only exception - 1.2 mod for '1.1 gameplay copy', when it will come out we will switch to 1.2 (our clan still w8 for full 1.2 release to work on this mod). When we talking about new engine, we talking about total upgrade, not about fork in development, so no global split.
How, exactly, is it "easier to dev"? Is there some sort of script to convert Trem maps to U3's format? IIRC, U3 was already ruled out anyway because of licensing issues (U3 is closed-source, Tremulous is GPL'd). XReal (along with Sauerbraten) is open-source, but you'd probably have to go through the same time-consuming processes no matter which engine you choose.
The biggest issue is this.
Porting is a pain, and getting Trem to XReal is a hard thing to do for people who have a life and a job.
Take something that would need a total recode such as U3 and the chance of porting plummets to almost nothing.
moving to U3 could be wouldnt be that much more work then xreal because it easier to dev.
waht im saying is you could port the current maps and models to u3 and plug in the game play manually
I don't remember Tremulous having models of enormous toads with bombs stuck in their asses.Oh come now, there's bound to be a mod for that.
Are you sure you're using the exact same settings for U3Trem and ioTrem (you said something about blur earlier)? Because I don't remember Tremulous having models of enormous toads with bombs stuck in their asses.
It's the updated 1.2 model silly.When did trem get a model silly?
what am i seeing, rotacak?You see 200 "turrets" inside base.
When rotacak got ahold of it.It's the updated 1.2 model silly.When did trem get a model silly?
or when the devs let the players developWhen rotacak got ahold of it.It's the updated 1.2 model silly.When did trem get a model silly?
I think to keep it realistic since tremulous has a very good gameplay we should do XReal and ignore other engines that need a total rewrite.Seconded. I keep bringing up Sauerbraten, but since there's no easy way to convert the maps (f**king octrees, how do they work?), it probably won't happen.
Besides you'd have to rewrite the code for U3.Soft bodies would be nice, but what would they do to the framerate? I'd imagine the vert count would skyrocket.
All you need for cloth is Bullet, if someone will go about integrating into XReal.
(I don't know how hard it is to get bullet into XReal)
I use bullet with Blender, softbodies work as cloth, jello, whatever.
Bullet does ridged bodies, plus some other features.
Plus Bullet is open source.
This has become quite a funny thread. Seven pages of speculation, "what if", daydreaming, totally unrealistic goals and needless pondering.Like "flying alien" for example? There was many threads about flying alien and almost all was spammed by users like you with text "go code it" "never happen" etc.
Hasn't anyone learned from the previous hundred threads? Doesn't anyone view this as really pointless...
This has become quite a funny thread. Seven pages of speculation, "what if", daydreaming, totally unrealistic goals and needless pondering.Quoted for truth. 1.2 is what the developers are working on now, and without their help, none of these changes will stand a chance. Everyone suggesting huge changes (porting for 1.2? really?), but apologetically ending your posts with an "Oh sorry, I can't do it, I don't have time", here's something you can do:
Hasn't anyone learned from the previous hundred threads? Doesn't anyone view this as really pointless since even thinking of it requires a) 1.2 to be released, and even then it is a highly unrealistic thing to really happen since there isn't any hint whatsoever of b) an actual team seriously committed to doing it.
Seriously, nothing else than poor screenshots with ATCS textures is going to happen out of this thread. At least you could stop rushing in prematurely, and wait for 1.2 to be released. Then there's an actual possibility to think what actually needs to be and could be changed for the next version and what tools there are to attain the goals. Thinking how stuff like vehicles would be so cool isn't really getting anywhere.
Amanieu and Thorn can be found on freenode (http://freenode.net/) in the #unvanquished channel, and if they're not available someone there can probably point you in the right direction.
I think only the armoured, shell part of the head and mouth with those fangs look good with that effect of yours.Armour: looks like he's infected with osteoporosis.
The rest of the goon looks pretty terrible, especially feet.
i could maybe help?With your mad l33t SketchUp skillz?
Just a few things I'd like to point out in this thread:Even though I don't support a Sauerbraten port, this issue needs to be cleared up. That's a bug in the networking code, which would probably be fixed at some point anyway to make it work with Tremulous. I'm not sure if that's even part of the engine, so much as the FPS demo included with it.
Tremulous is already ported to Xreal and works.
In my experience, the ONLY thing that did not work was the HUD.
The other thing I'd like to point out is that Sauerbraten's engine is terrible and you should stop suggesting it.
Have you ever tried to play a custom map in Sauerbraten? If you don't have the map, you can essentially choose to play on whatever map you want to and still shoot people from vantage points they don't have. You can kill people from a map they're not playing.
If that's not a bad engine, I don't know what is.
demand to create new entities for the new engine.Depends. for example xreal (afaik) support md3 and all quake stuff. So current stuff can be used with possibility of improvement. But anyway talks about it right now just waste of time. For me personally all clear, im not waiting for engine improvements anymore. All im waitng right now is final 1.2 release, so me and our clan devs can make 1.1-like mod with some improvements.
All im waitng right now is final 1.2 release, so me and our clan devs can make 1.1-like mod with some improvements.If you've got a clan with developers sitting around twiddling their thumbs why not get them working on an xreal port, or maybe even some of the bits and pieces that need to be sorted for 1.2(any good at sourcing audio?), since you're waiting for its release before you fiddle?
If there was a NEW engine that supported MD5's or something that good then I'd be making some of them.
There is no reason at all to make new flashy stuff then butcher them down to the craptastic MD3's.
If you've got a clan with developers sitting around twiddling their thumbs why not get them working on an xreal port, or maybe even some of the bits and pieces that need to be sorted for 1.2(any good at sourcing audio?), since you're waiting for its release before you fiddle?First at all.. devs obviously proved that they dont need some additional source code from community. And about XReal port. It demands client changing. Real and serious client changing. So its like creating new branch of a game, but while tremfusion users still can use official servers, xreal users cant (due to big difference between maps). Why should we waste time on things renounced by developers, and will not be used by community? All we can is make mod which changing server-side code and assets.
PS Also we too love Tremulous to just steal current assets/code and make 'XReal version' of the game. Trem community weak enough already to split it more. =\You're not going to split the trem community with a hastily bodged together port to xreal, it'll be a curiosity at best, but if you can't be arsed you can't be arsed, no problem.
Will you still use the 'official' version of the game, if there will be the same game, but on the XReal engine? The full transfer of data, similar gameplay, but with an improved engine and features. Personally, I would pass on an updated version of the game like many of my friends. That's what I mean when I talk about the split of community.Of course people would play a Tremulous with a better engine. You seem to assume though that the change will happen overnight. The playerbase won't really split since it'll take years to develop.
Of course people would play a Tremulous with a better engine. You seem to assume though that the change will happen overnight. The playerbase won't really split since it'll take years to develop.Not years if it just question of rendering engine upgrade. Especially considering that XReal is compatible with q3 and only few assets should be redone. =)
Only when it actually gets to the point where it's actually an improvement over the main distribution, which is going to require some considerable effort beyond just porting, if you get to that stage then you deserve to draw that attention and your work is valuable, the devs should want to work with your artists to improve the official trem release.The existence of the Tremfusion project refutes this. We have tested and fully working improved code, but no one care implement those features to main Tremulous branch. Why you think something gonna change after releasing of full XReal port?
If it's just a rendering engine upgrade you want, why even bother to upgrade? If you get nothing new and cool out of it?Of course people would play a Tremulous with a better engine. You seem to assume though that the change will happen overnight. The playerbase won't really split since it'll take years to develop.Not years if it just question of rendering engine upgrade. Especially considering that XReal is compatible with q3 and only few assets should be redone. =)
Hah, stop talking trash. Tremfusion had a huge amount of unnecessary and messy features, but it also introduced some nice things. You really don't seem to have noticed that a lot of those good features are already included in the next release. The project has also been dead for almost 1,5 years.Only when it actually gets to the point where it's actually an improvement over the main distribution, which is going to require some considerable effort beyond just porting, if you get to that stage then you deserve to draw that attention and your work is valuable, the devs should want to work with your artists to improve the official trem release.The existence of the Tremfusion project refutes this. We have tested and fully working improved code, but no one care implement those features to main Tremulous branch. Why you think something gonna change after releasing of full XReal port?
Tremfusion died without ever going anywhere, didn't it? Wasn't the plan for it to be more than just an enhanced 1.1 client?I cant make trem look like urthd for sure, obviously urt engine better, so when i'm working under trem engine i'm limited.
Talking up your developers abilities while using the long wait for 1.2 as an excuse for them to never make use of said abilities, nice, carry on.
Imagine, if you were working on a port you could get some practice in mapping with all those new features you so desperately want,
I bet you can't make trem look as pro as UrTHD though
/...screenshot excluded.../
If it's just a rendering engine upgrade you want, why even bother to upgrade? If you get nothing new and cool out of it?Its only answer to ideas 'we dont need to switch engine caus after it we strongly need redone all assets'. even with basic tremfusion improvements standart trem maps look like a lot better. And you always can release some sort of 'new assets' pack with improved models, sounds, maps, etc.
Hah, stop talking trash. Tremfusion had a huge amount of unnecessary and messy features, but it also introduced some nice things. You really don't seem to have noticed that a lot of those good features are already included in the next release. The project has also been dead for almost 1,5 years.Never heard about some real features from tremfusion was implemented to 1.2
If you dont get it i dont see point explain more.If it'll mean less crap being spouted, i welcome this decision.
We released InstaGib mod under 1.1 Trem already with bonuses, different footsteps, new possibilities, etc. So saying we not doing anything is lolly.ZOMG KILLAR FITURE!!!1! I haven't seen you produce anything vaguely interesting in the way of mods, i'm not for a moment disputing you mapping abilities.
I personally think as map my better than on your screenshot (uptown i think), more detailed, etc:The screenshot i posted was shit, every aspect of it, not just the map. But it's called HD, so it's awesome, right?
PS Crap, sorry guys... My English is too weak to accurately describe my ideas. =(I'm not sure that explains everything, sadly.
Tremulous really deserves better than oblivion after all these years.
Tremulous really deserves better than oblivion after all these years.Don't get your hopes up.
To be honest, I've given up on an "HD" Tremulous (we've apparently decided "HD" means "better models, more detailed textures, and an engine less than a decade old", so I'll go with that). There's too much infighting, too many conflicting goals, and not enough manpower to make Tremulous any more impressive to potential new players than it is. But finally getting 1.2 out, after more than 4 years, seems like an admirable goal for now.
Its Action, Strategy and no other game is like it. I was thinking steam but it needs to stay open source.There also Natural Selection 2. But i still think Tremulous is better. =D
Years? Seems it was Spanish instagib version. Our was made not so long time ago and it more improved than just 'tk+knockback' version.Taking a closer look at your map, the one i remember is pretty crude by comparison, is there a thread somewhere for your instagib?
But after all i'm not alone here, a lot of creative peoples working on Trem. Do you think they going refuse new possibilities?New possibilities are lovely, but they're not necessary to improve upon the existing game, we haven't hit the limits of ioq3 yet.
You just had to make me look that up, didn't you? Now I can't wait for it to come out. :oIts Action, Strategy and no other game is like it. I was thinking steam but it needs to stay open source.There also Natural Selection 2. But i still think Tremulous is better. =D
Assets already reached limit. =) MAy be im wrong, but can you give me example then?There are only a few alien, human, and buildable models/animations that look that good. The rest could be improved significantly. I very much think the community could make a competition or something to improve most of the models currently in the game (of course keeping in mind the upcoming chompers). Also, why not make a big graphical update on every default map for example, or work to make the sounds that need to be replaced? We've hardly reached a limit in anything in my opinion.
There are only a few alien, human, and buildable models/animations that look that good. The rest could be improved significantly. I very much think the community could make a competition or something to improve most of the models currently in the game (of course keeping in mind the upcoming chompers). Also, why not make a big graphical update on every default map for example, or work to make the sounds that need to be replaced? We've hardly reached a limit in anything in my opinion.New models and textures? Its not question of engine limits. I can make highly-detailed map and it gonna lag like hell... Or you improve human model and apply to it more detailed textures. Right now many players crying due to heavy ATCS lags on bases. No imagine what lags they gonna have with more-poly models and high-res textures. Q3 engine just not optimal enough for endless improvement and not supporting modern hardware acceleration. So thats limit. Using 1024x1024 textures with Q3 rendering procedures wont make much visual difference, only result will be much lags/fps drop. =\
I don't really get the we-need-an-engine-transition-i'm-not-creating-any-new-assets philosophy. That's just people being lazy. Make a great upgrade of an alien model for example, and I guarantee that it will be praised and included in the next version.
Using 1024x1024 textures with Q3 rendering procedures wont make much visual difference, only result will be much lags/fps drop. =\
Using 1024x1024 textures with Q3 rendering procedures wont make much visual difference, only result will be much lags/fps drop. =\Really? Many trem textures are extremely low res and some appear to have been wrecked by jpeg compression, do you really think we're at the upper limit there? You've talked about rebrushing existing textures in the past, do you feel it's not worth bothering now?
So you think the current stuff is at its max? Your honest opinion is that for example the human model is the best-looking, state-of-the-art quality one is able to make with Q3 without getting heavy performance problems?There are only a few alien, human, and buildable models/animations that look that good. The rest could be improved significantly. I very much think the community could make a competition or something to improve most of the models currently in the game (of course keeping in mind the upcoming chompers). Also, why not make a big graphical update on every default map for example, or work to make the sounds that need to be replaced? We've hardly reached a limit in anything in my opinion.New models and textures? Its not question of engine limits. I can make highly-detailed map and it gonna lag like hell... Or you improve human model and apply to it more detailed textures. Right now many players crying due to heavy ATCS lags on bases. No imagine what lags they gonna have with more-poly models and high-res textures. Q3 engine just not optimal enough for endless improvement and not supporting modern hardware acceleration. So thats limit. Using 1024x1024 textures with Q3 rendering procedures wont make much visual difference, only result will be much lags/fps drop. =\
I don't really get the we-need-an-engine-transition-i'm-not-creating-any-new-assets philosophy. That's just people being lazy. Make a great upgrade of an alien model for example, and I guarantee that it will be praised and included in the next version.
ioquake3 forces everything through the CPU and you hit performance limits with scenes involving 60,000 triangles on hardware that can easily do scenes of 1,000,000 to 10,000,000 triangles.
Its like driving car at max possible speed. You overheating engine, breaking car. Best engine is the one that has a reserve of power. Yes, we can improve all those things. But look... exchanging all jpeg textures will enlarge installer size. For example map with jpeg textures have 5mb size, but when i switch to tga sources it become over 20mb size. Real ingame effect (due to Q3 limitations) quite small. Sure we can do all that stuff and it will improve picture. But it's not worth it.
PS Lil example. One guy show me his new lasgun model (not so low-poly). That modal had 200 triangles more than old one. You can say its few, but... x10 humans at base with lasguns = 2000 triangles.
According ioQ3 specification:Quoteioquake3 forces everything through the CPU and you hit performance limits with scenes involving 60,000 triangles on hardware that can easily do scenes of 1,000,000 to 10,000,000 triangles.
So with every small improvement we closer and closer to engine 'red zone'. Most modern engines in addition to improved productivity as well use the effects to make the surface depth without increasing the number of triangles. Generalizing all the above - we can not seriously improve situation using the current engine.
But look... exchanging all jpeg textures will enlarge installer size. For example map with jpeg textures have 5mb size, but when i switch to tga sources it become over 20mb size.Are you serious? Don't use TGA for textures unless you need the alpha channel, JPEG is fine, but the existing textures can be redone at a slightly higher resolution and saved with a higher quality setting. Even if they're not scaled up, the textures are hardly state of the art, i feel there's some room for improvement even within the limits of existing resolutions.
Real ingame effect (due to Q3 limitations) quite small. Sure we can do all that stuff and it will improve picture. But it's not worth it.Not worth it why? Again, we're working around limitations of an old engine here, but do stannum's new weapon models and skins look no better than the existing ones? They seem pretty bloody good to me, as a layman.
we can not seriously improve situation using the current engine.You're right, but then we can't improve the situation with any engine, as we're all a bunch of lazy defeatists.
You're a big fan of UrT, it obviously uses higher poly models than trem but on the same engine, do you feel that it's unacceptably laggy because of this?Im big fan of Trem, not UrT. And about engine - urt dev improving it with every release to get better speed and quality, so you already cant say they 'just using ioQ3'
Im big fan of Trem, not UrT. And about engine - urt dev improving it with every release to get better speed and quality, so you already cant say they 'just using ioQ3'Every release? They've had two releases, one of which was the initial standalone, right? What kind of engine improvements went into 4.1?
I never said that just HD engine is awesome without any assets, etc. I only said that with improved engine Trem community gonna have possibilities bring game to new level of quality.
About mods... You never played our Instagib mod, right? =) And what about footsteps, heh? When you get different footstep sound when walking on grass it making game more atmospheric. Its just small detail. But such details making games good. Without attention to details games just plain.
PS Again about ur screenie. model looks better than in Trem, even with fact its from urt alpha and gonna be replaced. =]
The Unvanquished (http://unvanquished.net/forum/) is hosting a new community-driven project called TremHD (http://tremhd.unvanquished.net/forum/), which aims to make assets for Tremulous clients that utilize bump mapping features, as well as implement better support for wide-screen displays.Where's the IRC channel you keep mentioning?
The TremHD forums will serve as a roadmap for development, as well as a place to discuss and learn the techniques needed to make the new assets.
The project has not officially 'launched' yet, but I would love to get some feedback on the site, and get some additional help setting things up if anyone has time! :D
He didn't...The Unvanquished (http://unvanquished.net/forum/) is hosting a new community-driven project called TremHD (http://tremhd.unvanquished.net/forum/), which aims to make assets for Tremulous clients that utilize bump mapping features, as well as implement better support for wide-screen displays.Where's the IRC channel you keep mentioning?
The TremHD forums will serve as a roadmap for development, as well as a place to discuss and learn the techniques needed to make the new assets.
The project has not officially 'launched' yet, but I would love to get some feedback on the site, and get some additional help setting things up if anyone has time! :D
On the site.He didn't...The Unvanquished (http://unvanquished.net/forum/) is hosting a new community-driven project called TremHD (http://tremhd.unvanquished.net/forum/), which aims to make assets for Tremulous clients that utilize bump mapping features, as well as implement better support for wide-screen displays.Where's the IRC channel you keep mentioning?
The TremHD forums will serve as a roadmap for development, as well as a place to discuss and learn the techniques needed to make the new assets.
The project has not officially 'launched' yet, but I would love to get some feedback on the site, and get some additional help setting things up if anyone has time! :D
Barf, jpegs.Tremulous installer gonna be 2Gb size then =D
Isn't it finally time to abandon those lossy formats when space and bandwidth isn't an issue anymore?
Most games use the .DDS (http://en.wikipedia.org/wiki/DirectDraw_Surface) format for textures, they can be decompressed on the fly by the GPU.The compression is patented though...
P2P will fix all your woes.Nope. I dont need brick size cellular phone if other phone models can provide same functions with smaller size. Not question of 'how hard to download it'. =)
Yes, but the game engine does not need to decompress the data, and there are free tools (http://code.google.com/p/nvidia-texture-tools/) available for compression which have licensed (http://code.google.com/p/nvidia-texture-tools/wiki/FAQ#Can_I_use_the_NVIDIA_Texture_Tools_in_the_US?_Do_I_have_to_obtai) the S3 patent.Most games use the .DDS (http://en.wikipedia.org/wiki/DirectDraw_Surface) format for textures, they can be decompressed on the fly by the GPU.The compression is patented though...
Tremulous installer gonna be 2Gb size then =DThe stock maps are about 50MB now, i highly doubt they would increase in size by a multiple of 40.
The stock maps are about 50MB now, i highly doubt they would increase in size by a multiple of 40.When user downloading game of such size he expect something more than pack of high-res art.
Even if they were 2GB is not a problem.
Even if we took the brute-force approach and stored everything with some batshit-insanely high-quality format like Targa, keep in mind everything gets compressed in the pk3 files, and textures don't take up the whole archive as it is.Live example: Map with jpegs 4mb. Same map with original tgas 29mb. Not so huge visual difference. When i conecting to slow server i should wait x7 more time to download map. =D
Ahem.Even if we took the brute-force approach and stored everything with some batshit-insanely high-quality format like Targa, keep in mind everything gets compressed in the pk3 files, and textures don't take up the whole archive as it is.Live example: Map with jpegs 4mb. Same map with original tgas 29mb. Not so huge visual difference. When i conecting to slow server i should wait x7 more time to download map. =D
everything gets compressed in the pk3 files
Have you actually looked through the asset files? Textures are nothing compared to model files.Erm, yep, welcome to discussions involving CATAHA, fun eh?
The tyrant model for example is 1,846 KB compared to it's texture which is just 77 KB.
It seems like on one hand you're complaining about the slight increase in texture size required for a big visual difference, and on the other hand you want XReal and all the fancy graphics that would add MUCH more to the size. Nevermind that you then have to also recreate all the assets anyway...
Have you actually looked through the asset files? Textures are nothing compared to model files.Zipped tyrant is 1.2 MB. Anyway, go compare amount of textures and amount of models. Also tyrant seems be one of the "heaviest" models. I guess all models put together wouldn't take more than 15-20MB (simple guess, as weapons md3's take less than 50KB each), while texture set for arachnid is 8MB.
At the very least, we could save the JPGs with a higher quality setting. The increased file size might even get trimmed down a bit more with the pk3 compression.Only barely, if at all, some images may even grow but i suppose all those headers will give you a saving in bulk, anyway, JPEG compression works so well for most textures that the savings are big enough even when jpeg'd at quite high quality settings.
Where's this discussion going, anyway?I don't know, but this is where it should be going:
The Unvanquished (http://unvanquished.net/forum/) is hosting a new community-driven project called TremHD (http://tremhd.unvanquished.net/forum/), which aims to make assets for Tremulous clients that utilize bump mapping features, as well as implement better support for wide-screen displays.
The TremHD forums will serve as a roadmap for development, as well as a place to discuss and learn the techniques needed to make the new assets.
The project has not officially 'launched' yet, but I would love to get some feedback on the site, and get some additional help setting things up if anyone has time! :D
Have you actually looked through the asset files? Textures are nothing compared to model files.Zipped tyrant is 1.2 MB. Anyway, go compare amount of textures and amount of models. Also tyrant seems be one of the "heaviest" models. I guess all models put together wouldn't take more than 15-20MB (simple guess, as weapons md3's take less than 50KB each), while texture set for arachnid is 8MB.
Every few months there's a thread just like this, which makes me somewhat hoping for an XreaL port of Trem. Every one of these threads ends disappointingly with nothing.
Until someone(with actual knowledge in how this stuff works) does something to make that a reality, you're wasting your time.
Well there have been not only threads but also projects to port Trem over to Xreal, i know of the Tremfusion attempt to include a Xreal-based renderer and the Xtr3m project.
I think the big problem with this kind of project is that they lack a clearly defined goal. Usually they start with 'we want some nicer graphics', but then the want-to-have list is expanded (correct physics, vehicles, scriptable maps, game modes, new weapons/classes, whatever) until the project is so big that it is completely impossible to do with the available people.
Also, you need to factor in the degree of visual improvement. For example, the basi has a tiny texture size (even when summing the sizes of the base and adv version) compared to it's model size which is more than the tyrant's. Yet the texture looks good and I would go as far as to say it's the best looking alien by far.
Well, I have implemented an IQM loader for tremulous, (it is a much nicer format than MD5), so you could use skeletal models in Tremulous already. The problem is that if you can't switch all players over to the new model format at the same time you'll have to include *both* in the pk3s.
At the very least, we could save the JPGs with a higher quality setting. The increased file size might even get trimmed down a bit more with the pk3 compression.Only barely, if at all, some images may even grow but i suppose all those headers will give you a saving in bulk, anyway, JPEG compression works so well for most textures that the savings are big enough even when jpeg'd at quite high quality settings.
As asvarox mentions, the difference between TGA and PNG for our purposes is only really at what stage the compression is applied, it being practically the same compression method and raw data, yes zipping a TGA is somewhat less efficient but for the kind of resolutions we're talking about the size differences wont be huge.
JPEG artifacts, as with any other image quality deficiencies, will become more visible when the image is stretched across a model, but are they so noticeable that they'll be a problem if the texture's higher res to begin with, only jpeg'd the once and at a decent quality setting?
Where's this discussion going, anyway?
TGA supports RLE compression, but is not truly losslessOh, how so?
Yes the ZIP compression for the PK3s basically does nothing to an already compressed file format like JPEG or PNG.
TGA supports RLE compression, but is not truly losslessOh, how so?
And what does an 8bit pcx achieve that an 8bit png wouldn't? i'm a little surprised to see pcx mentioned at all thesedays.
Shaders cannot do that.
I think I found something which _seems_ to accomplish what I was looking for, but I lack the knowledge how shaders really work, so please check if it's a viable solution. Basically what this method is about is that, after a blendFunc GL_DST_COLOR GL_SRC_ALPHA step another blendFunc filter will "mask" the second texture according to the first greyscale alpha texture. I've tried it with two transparent textures, and the results seem to be the same.
First example is the metafloor_wall_14_specular texture (OA doesn't use it yet, but you can find it in q3dm16).
(http://udionline.hu/kepek/openarena/pcx-experiment/screen-specular.jpg)
The separated pcx solution is a little bit darker, according to the heppler reference, it's due to the additional blendFunc. The shader definitions used (left the transparent TGA, right the two PCX):
textures/base_wall/metalfloor_wall_14_specular {
qer_editorimage textures/base_wall/metalfloor_wall_14
{
map $lightmap
rgbgen identity
}
{
map textures/base_wall/metalfloor_wall_14_specular
rgbGen identity
blendFunc GL_DST_COLOR GL_SRC_ALPHA
}
}textures/base_wall/metalfloor_wall_14_specular {
qer_editorimage textures/base_wall/metalfloor_wall_14
{
map $lightmap
rgbgen identity
}
{
map textures/base_wall/metalfloor_wall_14_specular-alpha.jpg
rgbGen identity
blendFunc GL_DST_COLOR GL_SRC_ALPHA
}
{
map textures/base_wall/metalfloor_wall_14_specular-color.pcx
rgbGen identity
blendFunc filter
}
}
Filesizes (512x512px):
metalfloor_wall_14_specular.tga: 1.0 MB
metalfloor_wall_14_specular-alpha: 248.7 kB (8bit PCX) or 194.9 kB (grayscale JPG)
metalfloor_wall_14_specular-color: 259.5 kB (8bit PCX)
Sum: 1024 kB vs. 508.2 kB
The another example is the cybergrate2 shader, which you can find on the railgun platform of oa_ctf4ish. It's trickier than the previous, because only the metal grid was transparent, the electricity effect wasn't, but due to the method both had to be made transparent. The result:
(http://udionline.hu/kepek/openarena/pcx-experiment/screen-transparency.jpg)
The PCX solution is a bit ugly on the edges, but don't worry about that. Shaders used (left original, right new):
textures/base_floor/cybergrate2
{
surfaceparm metalsteps
cull none
{
map textures/sfx/portal_sfx_ring_electric.tga
tcmod scroll 1 -1
blendfunc add
}
{
map textures/base_floor/cybergrate2.tga
blendFunc blend
rgbGen identity
}
{
map $lightmap
blendFunc filter
rgbGen identity
}
}textures/base_floor/cybergrate2
{
surfaceparm metalsteps
cull none
{
map textures/sfx/portal_sfx_ring_electric-alpha.pcx
tcmod scroll 1 -1
blendFunc GL_DST_ONE_MINUS_COLOR GL_SRC_ALPHA
}
{
map textures/sfx/portal_sfx_ring_electric-color.pcx
tcmod scroll 1 -1
blendFunc filter
}
{
map textures/base_floor/cybergrate2-alpha-mono.pcx
rgbGen identity
blendFunc GL_DST_ONE_MINUS_COLOR GL_SRC_ALPHA
}
{
map textures/base_floor/cybergrate2-color.pcx
rgbGen identity
blendFunc filter
}
{
map $lightmap
blendFunc filter
rgbGen identity
}
}
Filesizes (256x256px):
cybergrate2.tga: 132 kB
cybergrate2-alpha: 5.1 kB (8bit PCX) or 3.6 kB (1bit PCX)
cybergrate2-color: 35.7 kB (8bit PCX)
Sum: 132 kB vs. 40.8 kB
Here's a test package so you can try this at home: http://udionline.hu/fajlok/z_pcx-experiment.pk3 (http://udionline.hu/fajlok/z_pcx-experiment.pk3)
The filesize compression is more than 50% in both cases, but of course the shader steps require more computing. Is it worth to deal with this method?
WE NEED SMOOTH SHADING!
Really everything right now renders solid :(
I visited the forums and saw just that post, at no point did it explain to me how TGAs are lossy or why you'd use PCX instead of PNG, maybe another poster explained that elsewhere but i assumed your copy-paste would have contained that salient piece of information had it been readily available.TGA supports RLE compression, but is not truly losslessOh, how so?
And what does an 8bit pcx achieve that an 8bit png wouldn't? i'm a little surprised to see pcx mentioned at all thesedays.
Since you were too lazy to visit the OA forums, here's a post in it's entirety about this:
*snip*
I was wrong, targas compressed with RLE compression claim to be loseless. However, I guess undesirable antialiasing can occur in TGAs with a lower color depths (lower than 24-bit?)Undesirable anti-aliasing? do you have a fondness for jaggies? So, back to the question, what's this guy's love of PCX all about? Is PCX treated in some special way by ioq3? Is there a good reason that the guy's storing 151 shades of grey as an indexed PCX rather than a greyscale PNG(of course i'm just assuming ioq3 supports PNGs here, i don't know)?
@tremulant: I guess cron meant to say Colour banding (http://en.wikipedia.org/wiki/Colour_banding).Yes, i assumed that was probably what he was getting at.
http://tremhd.unvanquished.net/forum/index.php?topic=18.0 (http://tremhd.unvanquished.net/forum/index.php?topic=18.0)Use a better image host. imgur/photobucket/tinypic/anything besides the site you just used. Also, that's not how the img tag works.
Got any suggestions for Friend Basi 2.0? :basilisk:
UPDATE: Working on model sheets for the Pazilisk, photos when I'm done.
Rough pencil sketch, uncolored:
(http://thumbnails41.imagebam.com/11846/1df1c4118452837.jpg) (http://www.imagebam.com/image/1df1c4118452837)
[img width=640]http://some.png[/img]For everything else, the IMG tag can be used like:Yeah, I figured that out while you were writing this. And thanks for that idea, I might animate the grab that way. Still, the basi is supposed to be a stealthy creature, with a small profile, and I think those spindly legs work well with that.Code: [Select][img width=640]http://some.png[/img]
For what it's worth, I think it should appear that the basi's legs/claws could stab through human legs and feet to grab them (in addition to grabbing them with their mouth?), ie, looking and acting like they are heavy and sharp.
i know this is a very old topic, but i remembered, does anyone have the link to download the textures? I could use it if i were to make a trem promo to try to keep trem from dying. Since last year, tremulous has lost about 30 servers on the masterlist, and about 20 players at any time average. [these are my estimations btw]Which textures and how are textures going to stop trem dying?
[these are my estimations btw]Cool, no reason to believe them whatsoever.