Water on the Mac; and lens flare(?)
by Scott Kearney · in Torque Game Engine · 07/22/2003 (10:20 pm) · 15 replies
Does water render differently on the Mac? I just built the source on my Win32 machine using mingw, and it appears that the water is using one of the more recent water implementations that gives it a less distinct "shoreline" (looks really nice!) The Mac version is more Tribes2-ish with the harsh, opaque seam between dry and wet.
Also, the Windows build has a "sun" on Waterworld, whereas the Mac does not. It's a very nice lens-flarey affect. Are these things not implemented on the mac? I can't find a mention of them in the readme.txt in the pb folder, which seems to be relatively current, and lists other "known issues".
edit: Stupid addendum I should make a note of before anyone bothers answering...my mac machines (there are two) have a Radeon Mobility and a GeForce2 MX. My Win32 machine has a GeForce4 Ti4200, so there's a decent discrepancy in vidcards. I don't remember seeing any difference between the two macs, though. I would think that the Radeon has a comparable feature-set to the GF4, though (but a lot slower).
Also, the Windows build has a "sun" on Waterworld, whereas the Mac does not. It's a very nice lens-flarey affect. Are these things not implemented on the mac? I can't find a mention of them in the readme.txt in the pb folder, which seems to be relatively current, and lists other "known issues".
edit: Stupid addendum I should make a note of before anyone bothers answering...my mac machines (there are two) have a Radeon Mobility and a GeForce2 MX. My Win32 machine has a GeForce4 Ti4200, so there's a decent discrepancy in vidcards. I don't remember seeing any difference between the two macs, though. I would think that the Radeon has a comparable feature-set to the GF4, though (but a lot slower).
#2
waterblock.cc, line 301
// Calculate Position of Texel Block Origin.
pTexelBlockOutput = pDepthBits + (U32)(s + (t * YStride));
// Write Point Height to Texel.
*pTexelBlockOutput = convertLEndianToHost(FluidPointColour);
Credit goes to David Chiat for pointing me in the right direction for this. He took a few moments to help me out, at a time when he was neck deep in code & against a deadline.
07/25/2003 (1:12 pm)
This change will fix the water depth rendering in the current HEAD, which is Melv May's improved waterblock code.waterblock.cc, line 301
// Calculate Position of Texel Block Origin.
pTexelBlockOutput = pDepthBits + (U32)(s + (t * YStride));
// Write Point Height to Texel.
*pTexelBlockOutput = convertLEndianToHost(FluidPointColour);
Credit goes to David Chiat for pointing me in the right direction for this. He took a few moments to help me out, at a time when he was neck deep in code & against a deadline.
#3
07/25/2003 (2:46 pm)
I'll try this out when I get home, thanks! Is there any reason why I only get the "crappy" water on the Mac, by default? I mean this in contrast to Windows, where I get nice water without the above change...
#4
So, all wintel hardware is Little-Endian, and the rest of the world is Big-Endian. The upshot is that in many many cases that difference has to be rectified to make some stuff work. Anything that looks at the individual parts of a large number stored in memory will see it arranged differently on pc & mac. Sometimes colors will appear to be stored RGBA on one platform and ABGR on another. As you see, this can mess stuff up.
It messes up the transperancy for the water, it messes up the fog color of distant terrain. Make the fog blue & dense, you will see the distant terrain & dif objects light up yellow. There's a different fix for that I found buried in the forums from way back.
So you see, its not that someone turned on 'crappy' water by default, its that the fella that contributed that code has a wintel box. He couldnt test with a mac.
07/25/2003 (5:01 pm)
There is a major difference between x86 hardware and the rest of the world. x86 stores 32 bit values bass-ackwards, for historical reasons. Its a thing they had to do to maintain compatability back in the day.So, all wintel hardware is Little-Endian, and the rest of the world is Big-Endian. The upshot is that in many many cases that difference has to be rectified to make some stuff work. Anything that looks at the individual parts of a large number stored in memory will see it arranged differently on pc & mac. Sometimes colors will appear to be stored RGBA on one platform and ABGR on another. As you see, this can mess stuff up.
It messes up the transperancy for the water, it messes up the fog color of distant terrain. Make the fog blue & dense, you will see the distant terrain & dif objects light up yellow. There's a different fix for that I found buried in the forums from way back.
So you see, its not that someone turned on 'crappy' water by default, its that the fella that contributed that code has a wintel box. He couldnt test with a mac.
#5
I did not know that.
That definitely fixed it. Do you have any idea about the "sun" that shows up in Windows (on the Waterworld demo at least)? Is it something similar? It seems like a complete addition, as opposed to a different rendering.
07/25/2003 (8:24 pm)
Well...I did not know that.
That definitely fixed it. Do you have any idea about the "sun" that shows up in Windows (on the Waterworld demo at least)? Is it something similar? It seems like a complete addition, as opposed to a different rendering.
#6
The file that renders that flare is fxSunLight.cc . Be sure it and other new files are in fact added to the pb project, and are getting compiled in.
If you have a message in your console.log file that says something like: "Unable to instatntiate non ConObject class Something" , then its a dead giveaway that you're missing some files in that project.
07/25/2003 (9:06 pm)
Assuming the sun flare is there in the mission editor... I'd say that you are compiling with ProjectBuilder, and that the pb project hasnt been updated with the new files.The file that renders that flare is fxSunLight.cc . Be sure it and other new files are in fact added to the pb project, and are getting compiled in.
If you have a message in your console.log file that says something like: "Unable to instatntiate non ConObject class Something" , then its a dead giveaway that you're missing some files in that project.
#7
07/25/2003 (9:37 pm)
Awesome. Thank you so much, Paul. 
#8
I only just saw this post so sorry I've not been around to help you with this.
Paul is dead-center with his advice here. David contacted me earlier this year when he mentioned that he was doing a port for one of the GG games ( can't remember which one ) and was encountering problems with the water code. I mentioned that the only thing I could think of where there were potential compatibility problems was the bitmap construction for the shoreline textures and sure enough David found it. I can't remember if David sent me the update for the endian problem or not but I should get this sorted if it's not already been done.
Again, Paul is correct in pointing out that it looks like you're simply not getting the fxSunLight.cc code compiled as your script error seems to indicate.
I should contact David to see if he can help out on this.
Sorry for your problems.
- Melv.
07/26/2003 (3:55 am)
Scott,I only just saw this post so sorry I've not been around to help you with this.
Paul is dead-center with his advice here. David contacted me earlier this year when he mentioned that he was doing a port for one of the GG games ( can't remember which one ) and was encountering problems with the water code. I mentioned that the only thing I could think of where there were potential compatibility problems was the bitmap construction for the shoreline textures and sure enough David found it. I can't remember if David sent me the update for the endian problem or not but I should get this sorted if it's not already been done.
Again, Paul is correct in pointing out that it looks like you're simply not getting the fxSunLight.cc code compiled as your script error seems to indicate.
I should contact David to see if he can help out on this.
Sorry for your problems.
- Melv.
#9
Don't sweat it, as far as I'm concerned, this is all bonus. Your improvements to the water code (and is the sun code yours too?) are great! I was just being greedy...and maybe a little indignant on thinking the mac was being neglected. ;-)
At any rate, with all you've contributed for the engine, I don't think you need to spend extra time apologizing!
07/26/2003 (11:43 am)
Melv,Don't sweat it, as far as I'm concerned, this is all bonus. Your improvements to the water code (and is the sun code yours too?) are great! I was just being greedy...and maybe a little indignant on thinking the mac was being neglected. ;-)
At any rate, with all you've contributed for the engine, I don't think you need to spend extra time apologizing!
#10
And the real question - who's responsible for getting these fixes/changes back into the Mac head?
07/27/2003 (10:38 pm)
Thanks Paul and Melv - the water esp. makes a huge difference in appearance. Waterblock.cc is still too difficult for me to try and parse (tired, still learning C ;) - how often in the rendering pipeline/loop is that convertendian being called, and would it be better to fix FluidPointColor somehwere else?And the real question - who's responsible for getting these fixes/changes back into the Mac head?
#11
The depth-map that we're talking about here, happens once only when the mission is loaded up and takes very little time. It is a simple matter to cache the file ( as per the scene lighting does ) on disk to save this step.
Responsibility is a strong word; we're all volunteers here. :) I'll drop a line to David and see what I can come up with. Got a busy week this week as I'm finalising some stuff for our game as I go away to Italy for two weeks starting next week.
- Melv.
07/28/2003 (12:13 am)
Matthew,The depth-map that we're talking about here, happens once only when the mission is loaded up and takes very little time. It is a simple matter to cache the file ( as per the scene lighting does ) on disk to save this step.
Responsibility is a strong word; we're all volunteers here. :) I'll drop a line to David and see what I can come up with. Got a busy week this week as I'm finalising some stuff for our game as I go away to Italy for two weeks starting next week.
- Melv.
#12
As for "responsibility", I meant that someone is the moderator for the Mac changes to the codebase. The reason Torque was intriguing is that it's cross-platform. As fixes and additions and such are created, I expect them to be added to the Mac side. If it's up to us to submit them, then so be it, but someone ultimately is in charge. I bought Torque knowing many things, esp. on the content-creation side, weren't up to speed on the mac side. I understand that anyone serious about doing a project will spend the $400 for a passable PC to at least test on. On the flip side, I paid the full price for Torque (albeit a very good price) which is supposed to be cross platform, not half price for the Kinda-sorta working Torque.
Whoa, that turned into a bit of a rant. ;) Uh, yea. So, what other files/features aren't being compiled into my learning/test project?
07/28/2003 (1:29 pm)
Melv - thanks, I'm still working through the documentations (such as it is) and don't have a high-level understanding of how the engine works. I was just checking to make sure we weren't doing an Endian convert every frame or somesuch.As for "responsibility", I meant that someone is the moderator for the Mac changes to the codebase. The reason Torque was intriguing is that it's cross-platform. As fixes and additions and such are created, I expect them to be added to the Mac side. If it's up to us to submit them, then so be it, but someone ultimately is in charge. I bought Torque knowing many things, esp. on the content-creation side, weren't up to speed on the mac side. I understand that anyone serious about doing a project will spend the $400 for a passable PC to at least test on. On the flip side, I paid the full price for Torque (albeit a very good price) which is supposed to be cross platform, not half price for the Kinda-sorta working Torque.
Whoa, that turned into a bit of a rant. ;) Uh, yea. So, what other files/features aren't being compiled into my learning/test project?
#13
AFAIK the changes, I agree that things should be kept in sync as much as possible. If something is added to CVS that's platform-dependent, that's understandable...but it would be nice if careless people like me didn't get tripped up by simple things like files just not being added to the powerbuilder project. All additions to HEAD should be tested out on all "supported" compile environments, in a perfect world.
That's not a complaint, just my two cents. That's what I think should be done, if, say, the GG team are sitting around, sipping martinis, thinking "Hmmm, what should we do?".. As far I am concerned, Torque rocks. Maybe when I know what I'm doing, I might start actually complaining about things :-)
07/28/2003 (2:06 pm)
I think David Chait is the man you're looking for. His name is on the CVS contributor's list, and he seems to be the token "mac guy" around here. I don't know if he's an employee or associate or what, though.AFAIK the changes, I agree that things should be kept in sync as much as possible. If something is added to CVS that's platform-dependent, that's understandable...but it would be nice if careless people like me didn't get tripped up by simple things like files just not being added to the powerbuilder project. All additions to HEAD should be tested out on all "supported" compile environments, in a perfect world.
That's not a complaint, just my two cents. That's what I think should be done, if, say, the GG team are sitting around, sipping martinis, thinking "Hmmm, what should we do?".. As far I am concerned, Torque rocks. Maybe when I know what I'm doing, I might start actually complaining about things :-)
#14
I'll drop that email to David.
- Melv.
07/28/2003 (2:13 pm)
I tend to think that it's the responsibility of the originator whether it be code or artwork .... damn, that makes it my problem now ..... darn it! :)I'll drop that email to David.
- Melv.
#15
I had (a few months back) gone through a concerted effort of a few weeks in a row fixing incremental bits that weren't working for people, but it seemed that in the last month Mark had checked in something not realizing it had Mac issues. It happens. Usually things surface quickly and get fixed. But sometimes you have to drop the GG folks emails, as they don't always scan the forums as much as they should.
I've fixed certain 'Mac Issues' in my side projects, mostly side resources like Ogg or MelvStuff, but as I haven't had time to keep up an active TGE HEAD project, those fixes haven't gotten back in. Usually though I've passed the details along to someone else in the community so it'd at least get out to the people needing it.
Unfortunately, what little side time I have at the moment is dedicated to Orbz, Tennis Critters, and ThinkTanks... and my day job just picked up steam, so that 'little side time' has shrunk a lot... At least for the next few weeks, I still just don't have time/bandwidth to do anything touching the main TGE codebase.
HOWEVER, there is a good response to submitting fixes to the GG guys, and they can certainly build and test stuff (in the pre-Marble Blast days they had no Mac in the office... I was a one man wreaking crew!). So post fixes, ping Mark (I think he's the 'Mac guy' for the moment @ GG), and I'll keep watching and chiming in when I can.
-d
07/31/2003 (7:01 pm)
I was the force behind the Mac platform support code, and had kept it up to date for about a year and a half. But the day job, and three Torque side-projects, has kept me pretty busy. I know that Mark has been doing his best to watch the Mac, but GG is still small, and there's only so much they can do at one time. :)I had (a few months back) gone through a concerted effort of a few weeks in a row fixing incremental bits that weren't working for people, but it seemed that in the last month Mark had checked in something not realizing it had Mac issues. It happens. Usually things surface quickly and get fixed. But sometimes you have to drop the GG folks emails, as they don't always scan the forums as much as they should.
I've fixed certain 'Mac Issues' in my side projects, mostly side resources like Ogg or MelvStuff, but as I haven't had time to keep up an active TGE HEAD project, those fixes haven't gotten back in. Usually though I've passed the details along to someone else in the community so it'd at least get out to the people needing it.
Unfortunately, what little side time I have at the moment is dedicated to Orbz, Tennis Critters, and ThinkTanks... and my day job just picked up steam, so that 'little side time' has shrunk a lot... At least for the next few weeks, I still just don't have time/bandwidth to do anything touching the main TGE codebase.
HOWEVER, there is a good response to submitting fixes to the GG guys, and they can certainly build and test stuff (in the pre-Marble Blast days they had no Mac in the office... I was a one man wreaking crew!). So post fixes, ping Mark (I think he's the 'Mac guy' for the moment @ GG), and I'll keep watching and chiming in when I can.
-d
Torque Owner Paul Scott
Default Studio Name