Ok, I hadn't had much time to go over the armagetron code yet, so let's get the discussion going, and pick up Lucifer's flamebait:
Lucifer wrote:
> Face it, guys, our rendering engine is better.
I made two screenshots with Armagetron 0.2.8 beta 4.2:
1) http://www.gltron.org/images/armagetron-lighting.png
Look at the cycle. Face it guys, we've seen better lighting on IBM-PCs with EGA graphics (for example in LHX attack chopper).
The screenshot would have been even more embarassing if I had some control over the camera (somehow, I can see no correlation between mouse and camera movements, even when I set the camera mode to 'free').
2) http://www.gltron.org/images/armagetron-reflections.jpg
Hah! It's not a reflection! It's just a bunch of mirrored geometry!
Of course the right way to do this is:
- Draw reflector to stencil buffer
- Draw mirrored geometry (clipped to reflector plane) where stencil is set
- Blend reflector into the scene
- Optionally add drop shadows to reflector
Depending on the amount of reflectivity, you'll have to lighten your shadows (e.g. there's no shadows on a perfect mirror) too.
GLtron vs. Armagetron: technical comparision
Haha, I wrote a really long post, and then thought "Why can't I just keep my mouth shut until he's done?" 
Edit: I do want to point out the really low resolution of your screenshots. I play the game at 1280x800, and it looks substantially better at that higher resolution.
Edit: I do want to point out the really low resolution of your screenshots. I play the game at 1280x800, and it looks substantially better at that higher resolution.
Check out my YouTube channel: https://youtube.com/@davefancella?si=H--oCK3k_dQ1laDN
Be the devil's own, Lucifer's my name.
- Iron Maiden
Be the devil's own, Lucifer's my name.
- Iron Maiden
Inflammatory, geez. If I had said my wife was prettier than yours, or my kids cuter than yours, would that have been inflammatory? Egotistical, certainly. Inflammatory?
Ok, let's fight anyway.
Our rendering engine does a number of things yours doesn't. The mirror effect, whatever else you might have to say about it, is there, and if it weren't for the extreme level of configuration in the renderer, the flaws you exposed wouldn't be exposed. They'd be safely hidden. But they're not, because of the extreme level of configuration.
In short, by providing numerous ways to tweak the rendering engine, it's possible to get a playable framerate on very old machines that GLTron probably doesn't run on (based on how poorly it ran on my fairly modern machine) and still scale up to a modern machine with effects to match. Just ask iceman for his machine's specs one day.
So the variety of effects offered vary. You've got recognizers floating in the background. Framerate killing models that have no bearing on the game.... But they look really nice! No doubt about that. And you can turn them off, and that's awfully convenient. The halo effect you've got looks really nice too, very impressive!
But for some reason, when driving straight, with the recognizers off, at a low resolution, I could still only get what, max of 70fps? So maybe you intentionlly slowed it down. Certainly makes sense. Of course, according to our wiki, you need more than 70fps if its available in a computer game to establish the same level of realism in a 24fps movie. Average fps is a more useful statistic, which hovered around 30. So I could keep beating on the performance, and I think I'd like to, considering how many times I've sat through "GLTron runs at <this> framerate, why can't Armagetron do it?".
Let's see, only one camera view? I admit I didn't try grabbing the mouse, I consider using the mouse to control the camera and the keyboard to move to be counter-intuitive, no matter how many thousands of geeks playing counterstrike disagree with me. But I did look at keybinds to see if I could move the camera much. You might bitch about the camera we've got, but there is smartcam (which I personally prefer) and several other cameras, the most interesting being the custom camera. You've got a fair amount of control over the camera here, actually. Of course, that's to facilitate gameplay, and the general attitude around here is "better gameplay--who cares what it looks like". I'll bet I'm not the only one here that drives an ugly car that runs great past all the shiny cars that run like shit.
So, I've pulled out some other things I said there that you might find inflammatory. Here they are:
On the quality of code (not in comparison to ours):
But the thread was about cooperating, and I didn't see a lot of room for it based on the code as it stood at that time, and *only* on the code as it stood at that time. Maybe there are other factors that would make cooperation worthwhile to both of us, but I didn't see where we'd benefit by using your code (compared to the amount of work it would take to do so) or where you'd benefit by using ours.
Ok, let's fight anyway.
Our rendering engine does a number of things yours doesn't. The mirror effect, whatever else you might have to say about it, is there, and if it weren't for the extreme level of configuration in the renderer, the flaws you exposed wouldn't be exposed. They'd be safely hidden. But they're not, because of the extreme level of configuration.
In short, by providing numerous ways to tweak the rendering engine, it's possible to get a playable framerate on very old machines that GLTron probably doesn't run on (based on how poorly it ran on my fairly modern machine) and still scale up to a modern machine with effects to match. Just ask iceman for his machine's specs one day.
So the variety of effects offered vary. You've got recognizers floating in the background. Framerate killing models that have no bearing on the game.... But they look really nice! No doubt about that. And you can turn them off, and that's awfully convenient. The halo effect you've got looks really nice too, very impressive!
But for some reason, when driving straight, with the recognizers off, at a low resolution, I could still only get what, max of 70fps? So maybe you intentionlly slowed it down. Certainly makes sense. Of course, according to our wiki, you need more than 70fps if its available in a computer game to establish the same level of realism in a 24fps movie. Average fps is a more useful statistic, which hovered around 30. So I could keep beating on the performance, and I think I'd like to, considering how many times I've sat through "GLTron runs at <this> framerate, why can't Armagetron do it?".
Let's see, only one camera view? I admit I didn't try grabbing the mouse, I consider using the mouse to control the camera and the keyboard to move to be counter-intuitive, no matter how many thousands of geeks playing counterstrike disagree with me. But I did look at keybinds to see if I could move the camera much. You might bitch about the camera we've got, but there is smartcam (which I personally prefer) and several other cameras, the most interesting being the custom camera. You've got a fair amount of control over the camera here, actually. Of course, that's to facilitate gameplay, and the general attitude around here is "better gameplay--who cares what it looks like". I'll bet I'm not the only one here that drives an ugly car that runs great past all the shiny cars that run like shit.
So, I've pulled out some other things I said there that you might find inflammatory.
Here they are:On the quality of code (not in comparison to ours):
On the relationship of the players to the developers ( a real comparison, emphasis mine ):Lucifer wrote: I don't know about problematic, it looks like his code is solid code and well-designed at that. I didn't say this before, but it was clear looking at his code that he's a very good programmer. Smile C code can be ugly, but it usually isn't pretty, and when it is, that's the sign of a craftsman or an artist. And his C code was very pretty. It just doesn't do as much, feature for feature, as ours.
Lucifer wrote: I like Linux in large part because there was a great deal of focus on building a solid core first, then building the next stuff, then the next. We'll get there. Our current group of players is definitely very interested in playing the game rather than looking at shiny things. Everytime someone says "let's make it look prettier", 5 people (mostly not developers) jump in and say "No! Let's make it more fun!"
You've done good work, there's no question about that. Don't take it personally if someone else looks at it and basically says "I like this other renderer better, the differences are mostly a matter of taste." Sure, you can open up your hood and show us a really nice renderer, I know, I looked at it! (not that I know much about gl programming) And it's become something of a rite of passage around here to crack open the code and bash the renderer.andi wrote: Since I recently got a nice new model from someone who demanded I implement doom3 style shadow volumes, I did just that.
But the thread was about cooperating, and I didn't see a lot of room for it based on the code as it stood at that time, and *only* on the code as it stood at that time. Maybe there are other factors that would make cooperation worthwhile to both of us, but I didn't see where we'd benefit by using your code (compared to the amount of work it would take to do so) or where you'd benefit by using ours.
Check out my YouTube channel: https://youtube.com/@davefancella?si=H--oCK3k_dQ1laDN
Be the devil's own, Lucifer's my name.
- Iron Maiden
Be the devil's own, Lucifer's my name.
- Iron Maiden
Oh I see....Let's clear up the misunderstandings:
Claiming that Armagetron's engine was better than GLtron's irked me. A tiny bit. Mostly because I suspected you were right.
I claimed that the quotation was 'inflammatory' mostly to justify my 'harsh' response of pointing out two flaws in Armagetron's renderer (you have to admit, the screenshots make it look quite shitty), which made me feel better again. I tried to keep a humorous tone, but evidently failed. I guess I should make more conventional posts until we know each other better...
About the frame rate: Yes, it's capped. Hopefully to the vsync of your monitor (otherwise you'll get tearing). In-game physics is capped to 100 FPS. Also, since I work mainly on laptops, GLtron tries to release the CPU (and allow the laptop to go into power-saving mode) as much as it can.
I don't see why it shouldn't run well on old hardware (e.g. a G3 233 with a Rage Pro) if you disable the latest bells and whistles. An older version ran (and looked) satisfactory on a PC with a 400 MHz CPU using Mesa software rendering. I admit I haven't tried anything like that lately.
Thanks a lot for the nice comments on my coding style. Luckily you seem to have looked at code I had recently cleaned up, I'm quite sure there's still lots of ugliness hidden in there. I just want to point out one of the reasons I'm sticking (for the time being) to C (a very simple programming language) for this project. 1) It's easy to decide if some piece of code needs fixing (if it's not immediately obvious what it does (and why), it needs fixing) and 2) it's usually very easy to fix. I have arrived at this conclusion after working for the last few years on a project that required fixing and extending about two million lines of C++ code (created by dozens of programmers).
Back to the rendering engine issue. GLtron has not much of a 'rendering engine' yet. It's basically a series of calls to a few functions that pull out the game data from some global variables, and draw stuff to the screen. I've only recently (i.e .this year) started to write a 'real' 3d engine (most of the stuff in the nebu/ directory). So I agree with you, there's nothing useful there for you (yet).
However, a look at Armagetron's render code showed me that it's not much different there. Many values (e.g. light colors & direction) are hard coded locally in the game code, and your models even seem limited to a single material (e.g. you can't have differently colored specular highlights on the windows (usually white) and the hull (usually the same color as the hull - a property of most metals) of the lightcycle).
I disagree on the matter if these differences are mostly a matter of taste though. I tweaked the visuals of GLtron in some areas quite a bit (and of course, I neglected other areas completely), and I think the lighting is important. I also noticed that in armagetron, you seldom see the lightcycles 'up close' which diverges a lot from the mood of the movie (where you see the lightcycles up close most of the time). You can say that the camera being outside the arena (where you can see beneath the floor) is an extreme condition right now, but you'll run into the issue as soon as you try out some map layouts that are a bit more complex. But you can see from my last post that the issue is easy to fix.
Camera issues: I agree that the smart cam is doing ok if you just play the game, but it doesn't do much to 'show off' the looks of the game. Also, my main issue with the camera controls were that I had a hard time getting the camera where I wanted it so I could take nice screenshots which, admittedly, is not very relevant to the gaming experience (but very important if you want to tweak the appearance). On a unrelated note, GLtron 0.71 new default camera (I had several different camera modes for years, btw.) feels a lot like Armagetron's smart cam. If you run linux or win32, grab the beta from July from
Linux:
http://www.gltron.org/stuff/GLtron-0.71-beta-1015.sh
Windows:
http://www.gltron.org/stuff/gltron-0.71-beta-1015-1.exe
to try it out.
Claiming that Armagetron's engine was better than GLtron's irked me. A tiny bit. Mostly because I suspected you were right.
I claimed that the quotation was 'inflammatory' mostly to justify my 'harsh' response of pointing out two flaws in Armagetron's renderer (you have to admit, the screenshots make it look quite shitty), which made me feel better again. I tried to keep a humorous tone, but evidently failed. I guess I should make more conventional posts until we know each other better...
About the frame rate: Yes, it's capped. Hopefully to the vsync of your monitor (otherwise you'll get tearing). In-game physics is capped to 100 FPS. Also, since I work mainly on laptops, GLtron tries to release the CPU (and allow the laptop to go into power-saving mode) as much as it can.
I don't see why it shouldn't run well on old hardware (e.g. a G3 233 with a Rage Pro) if you disable the latest bells and whistles. An older version ran (and looked) satisfactory on a PC with a 400 MHz CPU using Mesa software rendering. I admit I haven't tried anything like that lately.
Thanks a lot for the nice comments on my coding style. Luckily you seem to have looked at code I had recently cleaned up, I'm quite sure there's still lots of ugliness hidden in there. I just want to point out one of the reasons I'm sticking (for the time being) to C (a very simple programming language) for this project. 1) It's easy to decide if some piece of code needs fixing (if it's not immediately obvious what it does (and why), it needs fixing) and 2) it's usually very easy to fix. I have arrived at this conclusion after working for the last few years on a project that required fixing and extending about two million lines of C++ code (created by dozens of programmers).
Back to the rendering engine issue. GLtron has not much of a 'rendering engine' yet. It's basically a series of calls to a few functions that pull out the game data from some global variables, and draw stuff to the screen. I've only recently (i.e .this year) started to write a 'real' 3d engine (most of the stuff in the nebu/ directory). So I agree with you, there's nothing useful there for you (yet).
However, a look at Armagetron's render code showed me that it's not much different there. Many values (e.g. light colors & direction) are hard coded locally in the game code, and your models even seem limited to a single material (e.g. you can't have differently colored specular highlights on the windows (usually white) and the hull (usually the same color as the hull - a property of most metals) of the lightcycle).
I disagree on the matter if these differences are mostly a matter of taste though. I tweaked the visuals of GLtron in some areas quite a bit (and of course, I neglected other areas completely), and I think the lighting is important. I also noticed that in armagetron, you seldom see the lightcycles 'up close' which diverges a lot from the mood of the movie (where you see the lightcycles up close most of the time). You can say that the camera being outside the arena (where you can see beneath the floor) is an extreme condition right now, but you'll run into the issue as soon as you try out some map layouts that are a bit more complex. But you can see from my last post that the issue is easy to fix.
Camera issues: I agree that the smart cam is doing ok if you just play the game, but it doesn't do much to 'show off' the looks of the game. Also, my main issue with the camera controls were that I had a hard time getting the camera where I wanted it so I could take nice screenshots which, admittedly, is not very relevant to the gaming experience (but very important if you want to tweak the appearance). On a unrelated note, GLtron 0.71 new default camera (I had several different camera modes for years, btw.) feels a lot like Armagetron's smart cam. If you run linux or win32, grab the beta from July from
Linux:
http://www.gltron.org/stuff/GLtron-0.71-beta-1015.sh
Windows:
http://www.gltron.org/stuff/gltron-0.71-beta-1015-1.exe
to try it out.
Hmmm, I've put quite a few hours I'd like to have back trying to get GLTron to run on this thing. 
Long story, but I've tried off and on over the last, ummm, 3 years? I think I made my first attempt before my first attempt to run Armagetron. (I don't know what version it was, but I didn't manage to Armagetron to run until 0.2.5, which came with the then-current version of Mandrake) I've got it building here, but I just upgraded my OS and am currently having a personality conflict with the upgrade. So we'll see. But if it still builds, I'd just as soon grab from cvs/svn/visual sourcesafe (heh).
I have no problem admitting that from many angles armagetron looks pretty bad. We're not all here addicted to it because it's pretty. And it feels quite rough around the edges. So much so that whenever I play it now I itch... (which is what led me to start working on a new sound engine for the thing)
I was pretty happy with the rendering I saw, and I"ll tell you why. It's separated from the rest. Yeah, ok, so it uses global variables. I wish we had something that simple, because it looks very easy to extend. In fact, if you were interested in working collaboratively to incorporate data structures and features that are compatible with ours, there is actually room for us to work together there. Had I the time, I'd gladly throw myself into something like that and go work on GLTron's renderer for the express purpose of turning it into a general-purpose light cycle rendering engine that could be brought back to Armagetron. Sadly, if I finish the work on the sound engine and the embedded webserver before school lets out in May, I'll consider myself overly productive.
Anyway, we're probably in agreement. I could go in detail through your post and say "Yeah, I agree with that". Good enough?
Long story, but I've tried off and on over the last, ummm, 3 years? I think I made my first attempt before my first attempt to run Armagetron. (I don't know what version it was, but I didn't manage to Armagetron to run until 0.2.5, which came with the then-current version of Mandrake) I've got it building here, but I just upgraded my OS and am currently having a personality conflict with the upgrade. So we'll see. But if it still builds, I'd just as soon grab from cvs/svn/visual sourcesafe (heh).I have no problem admitting that from many angles armagetron looks pretty bad.
We're not all here addicted to it because it's pretty. And it feels quite rough around the edges. So much so that whenever I play it now I itch... (which is what led me to start working on a new sound engine for the thing)I was pretty happy with the rendering I saw, and I"ll tell you why.
It's separated from the rest. Yeah, ok, so it uses global variables. I wish we had something that simple, because it looks very easy to extend. In fact, if you were interested in working collaboratively to incorporate data structures and features that are compatible with ours, there is actually room for us to work together there. Had I the time, I'd gladly throw myself into something like that and go work on GLTron's renderer for the express purpose of turning it into a general-purpose light cycle rendering engine that could be brought back to Armagetron. Sadly, if I finish the work on the sound engine and the embedded webserver before school lets out in May, I'll consider myself overly productive.Anyway, we're probably in agreement.
I could go in detail through your post and say "Yeah, I agree with that". Good enough?It's a mutual failure. No doubt if we were having this conversation over a couple of beers we'd be having a great time.I tried to keep a humorous tone, but evidently failed. I guess I should make more conventional posts until we know each other better...
Check out my YouTube channel: https://youtube.com/@davefancella?si=H--oCK3k_dQ1laDN
Be the devil's own, Lucifer's my name.
- Iron Maiden
Be the devil's own, Lucifer's my name.
- Iron Maiden
I always wondered if Armagetron and GLTron's developers would ever share code or talk about it. I'm really happy andi made that step, as I hope it will also bring those communities a bit closer to each other.
EDIT: ArmagetronAd decided to diverge from the movie concepts perhaps GLTron should focus on the movie fans.
I'd guess it would not hurt popularity if gltron and armagetronad used a compatible skin system (at least for cycles etc.).
btw. which kind of coordinate system does gltron use and which one do we have in Armagetronad ? Right handed coord-sys with positive Z axis out of the screen is OpenGL's default. Did both stick to that ?
EDIT: ArmagetronAd decided to diverge from the movie concepts perhaps GLTron should focus on the movie fans
.I'd guess it would not hurt popularity if gltron and armagetronad used a compatible skin system (at least for cycles etc.).
btw. which kind of coordinate system does gltron use and which one do we have in Armagetronad ? Right handed coord-sys with positive Z axis out of the screen is OpenGL's default. Did both stick to that ?
We're using z=up, too. Makes much more sense in a pseudo-2d game, where you want the relevant coordinates to be labeled x and y. For rendering, of course, the z-axis is the depth and x and y the screen coodinates. The camera code takes care of the transformation.
And the format expected for models does not need to correlate to the coordinates the game uses, there would not be a problem to have y=up there. Yes, not a big deal, just a matter of shuffling transformation matrices around.
Thanks about the reflection bug-report It will be corrected. Not with the stencil buffer, though, I consider that a needless waste of bandwidth in our case. I'll just make sure the floor extends far enough. I'd like the floor to be infinite in all directions anyway, but some stupid ATI cards get confused when you throw projective geometry at them.
Please excuse my silence on the other things, I'm suffering from the usual combination of a bad cold and holiday stress currently.
And the format expected for models does not need to correlate to the coordinates the game uses, there would not be a problem to have y=up there. Yes, not a big deal, just a matter of shuffling transformation matrices around.
Thanks about the reflection bug-report
It will be corrected. Not with the stencil buffer, though, I consider that a needless waste of bandwidth in our case. I'll just make sure the floor extends far enough. I'd like the floor to be infinite in all directions anyway, but some stupid ATI cards get confused when you throw projective geometry at them.Please excuse my silence on the other things, I'm suffering from the usual combination of a bad cold and holiday stress currently.
Waste of bandwidth? All known consumer hardware has a shared z/stencil buffer so you're reading writing that memory anyway and stenciling is essentially free. I wouldn't worry about performance before it shows up significantly in the benchmarks, and the cost of the mirrored geometry (and the associated fill-rate) is orders of magnitude higher than the additional stencil ops even if they're not free.
Modifying geometry is costly though: It requires extra programming, and it imposes restrictions on the level designers (e.g. they can't create holes in the floor).
Modifying geometry is costly though: It requires extra programming, and it imposes restrictions on the level designers (e.g. they can't create holes in the floor).
Yes, even though writing to the stencil buffer is free, you still have to draw the floor twice. The simple approach only has to draw it once. And your the cost analysis is not correct in all situations either: Fillrate from walls is quite minimal in some configurations. Most notably, I run AA with disabled floor rendering on both a GeForce FX 5200 and a GeForce2Go in 1600x1200, most of the time fluidly at 60fps. Just enabling the floor lets the framerate drop to 15fps (on the 2go). Of course, I don't have reflection enabled there, but you get the idea: rendering the floor once eats at least 75% of the fillrate. Disabling the floor texture reduces the load significantly, but it's still a waste.andi75 wrote:Waste of bandwidth?
And, also depending on the situation, holes may be added with less overall cost by just rendering them pitch black. We'll think about the tradeoffs when we support holes, right now we don't as they don't add gameplay value you don't also get by walls.
The floor is only a rectangle, not really costy to modify.