126
General Discussion / Re: Does Qhimm have an IRC channel?
« on: 2008-05-29 08:27:53 »
Might add it to my list of IRC servers too, so you may see me around too...
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
127
General Discussion / Re: Is it possible to get FFVII Text Dumps?
« on: 2008-05-29 07:28:20 »
Depends on what you want.
Cosmo already has the ability to dump all the text it finds for every field file out into text files. I wouldn't be surprised if some other editing tools could do this as well. Of course I suspect somebody has already done this so you can probably find the game script posted somewhere on the 'net already.
What an automatically generated dump isn't necessarily going to give you, is some indication of what order the various dialogue plays in. It's effectively a tree of dialogue, after all (although FF7 doesn't have very many branches...) so it's not just a case of reading down the list of lines in order and aha, that's exactly what you'd see/hear.
Cosmo already has the ability to dump all the text it finds for every field file out into text files. I wouldn't be surprised if some other editing tools could do this as well. Of course I suspect somebody has already done this so you can probably find the game script posted somewhere on the 'net already.
What an automatically generated dump isn't necessarily going to give you, is some indication of what order the various dialogue plays in. It's effectively a tree of dialogue, after all (although FF7 doesn't have very many branches...) so it's not just a case of reading down the list of lines in order and aha, that's exactly what you'd see/hear.
128
FF7Voice / Re: Has a FFVII Voice-Over Project ever been attempted?
« on: 2008-05-29 07:17:48 »
Bah, the old Cosmo off screen bug...easiest solution is to run Cosmo then hit Alt-Space to bring up the system menu (don't worry if you can't see it), and hit 'M' for 'move', then use arrow keys & mouse to bring it back on screen.
Two possibilities.
Firstly, identify the dialogue by ID - as dzuigo's app does. So every time a dialogue is displayed the tool knows, 'this is file NVL_W, dialogue #4". You'd then have used some sort of a field file viewer to go through and see what dialogue it contained, and recorded a file (e.g. NVL_W_04.wav) with the dialogue for whatever dialogue #4 said.
Secondly, identify the dialogue by text - more like my test app. So when the dialogue is displayed the tool knows, 'Cloud is saying "The black-caped man?"'. It then looks to see if you've recorded a file linked to that text and if so plays it. (It could also take into account the location you were in, of course.) You'd probably strip out a certain amount of formatting/punctuation to make matching it up easier.
The first approach is arguably more 'correct', but there are advantages and disadvantages to both approaches;
-If the text changes the first method will still play the audio, the second won't (say somebody has edited the field files). It's hard to say which is better! If all that's happened is that somebody has corrected a spelling error in the field file, you probably still want the audio to play. On the other hand, if somebody has changed the text totally you probably don't want the original audio to play! The second method would let you play a different file (if you knew what the new dialogue was), so you could in theory distribute a single voice pack that still worked (and actually played something different) when certain patches to the dialogue were installed.
-In a similar way, the first method would still work if you were running a foreign version of the game (provided the dialogue IDs matched up). Of course, would you want English dialogue on a French language game?
(That raises another issue; I know in the UK release they at least renamed 'Aerith' to 'Aeris' [thank goodness]; does anyone know if they actually changed any other dialogue? I'd assume not, but clearly it wasn't just a direct unaltered release...)
-The second method has the possibility that standard lines of text, or any lines of text said in more than one place, could be recorded just once and the tool could 'automatically' reuse them between different field locations.
The disadvantage of that would be you might not want it to do that...
Third one, I was hoping to have a theory to suggest here but since I couldn't take a look at the files as I would have liked I don't really have much to say. How would you guys think we could identify which dialog line is being called (basically ID it). I mean, we can show the text right now, but can we uniquely identify which text is shown so we can associate that identifier with a file to play it ? My guess from what I know would be that we'd need to identify the right field file in use but apart from that how could we tell which dialog is being called up by the game ?
Two possibilities.
Firstly, identify the dialogue by ID - as dzuigo's app does. So every time a dialogue is displayed the tool knows, 'this is file NVL_W, dialogue #4". You'd then have used some sort of a field file viewer to go through and see what dialogue it contained, and recorded a file (e.g. NVL_W_04.wav) with the dialogue for whatever dialogue #4 said.
Secondly, identify the dialogue by text - more like my test app. So when the dialogue is displayed the tool knows, 'Cloud is saying "The black-caped man?"'. It then looks to see if you've recorded a file linked to that text and if so plays it. (It could also take into account the location you were in, of course.) You'd probably strip out a certain amount of formatting/punctuation to make matching it up easier.
The first approach is arguably more 'correct', but there are advantages and disadvantages to both approaches;
-If the text changes the first method will still play the audio, the second won't (say somebody has edited the field files). It's hard to say which is better! If all that's happened is that somebody has corrected a spelling error in the field file, you probably still want the audio to play. On the other hand, if somebody has changed the text totally you probably don't want the original audio to play! The second method would let you play a different file (if you knew what the new dialogue was), so you could in theory distribute a single voice pack that still worked (and actually played something different) when certain patches to the dialogue were installed.
-In a similar way, the first method would still work if you were running a foreign version of the game (provided the dialogue IDs matched up). Of course, would you want English dialogue on a French language game?
(That raises another issue; I know in the UK release they at least renamed 'Aerith' to 'Aeris' [thank goodness]; does anyone know if they actually changed any other dialogue? I'd assume not, but clearly it wasn't just a direct unaltered release...)
-The second method has the possibility that standard lines of text, or any lines of text said in more than one place, could be recorded just once and the tool could 'automatically' reuse them between different field locations.
The disadvantage of that would be you might not want it to do that...
129
FF7Voice / Re: Has a FFVII Voice-Over Project ever been attempted?
« on: 2008-05-28 09:51:13 »
Yep, a hook is the way to go; not too difficult to implement. Proof of concept;
http://www.sylphds.net/ev2/img/dialogue1.png
Would need more work to implement sound playback on demand, etc, but at least we know it's fairly trivial to intercept the text as it gets displayed on the screen.
(Ignore the corrupted graphics, getting it working on my Mac is still a bit of a work in progress!)
http://www.sylphds.net/ev2/img/dialogue1.png
Would need more work to implement sound playback on demand, etc, but at least we know it's fairly trivial to intercept the text as it gets displayed on the screen.
(Ignore the corrupted graphics, getting it working on my Mac is still a bit of a work in progress!)
130
FF7Voice / Re: Has a FFVII Voice-Over Project ever been attempted?
« on: 2008-05-27 11:41:55 »Thanks for the feedback Ficedula.
I've been trying to understand how the game dialog works to see if my theory was correct on how to go at it (which is proving kind of hard since I have no programming skills ... at all) and reading Gears, I see you contributed some info to the Dialog and Event Field Format. Would you have any suggestion as to how this could be handled ?
I have one or two ideas about how it could work. I expect there's probably a number of approaches you could take to hook into the game and intercept the text display, but really technical investigation would be required to see how plausible any possible approach would be. The two that come to mind immediately are modifying the field files to try and play the sounds in-game, or writing an external utility (like FF7Music) that hooked events but did all the sound processing in a separate application. My personal feeling is that the second would be easier.
I'm willing to take a look at how possible something like this would be, but first I'll have to get FF7 working on my current computer!
I hope Ficedula gets involved as a Voice Over
I'd be happy to contribute my smoooooth British accent if the project got off the ground, but I don't know I'd be suitable for a main character. If nothing else, the time involved in recording a large amount of dialogue is probably more than I could commit to at the moment.
131
FF7Voice / Re: Has a FFVII Voice-Over Project ever been attempted?
« on: 2008-05-26 11:27:28 »
Aside from the issue of how good such a mod would be, I'm afraid to say that FF7Music really wouldn't be any use for this. It doesn't monitor what the game is doing very closely at all - all it really knows is when the music track changes. (The same technique can be used to find out when the location changes - but not anything more detailed, like which line of dialogue is showing on the screen...)
This isn't to say that couldn't be done; it could, but it would require a completely different method of hooking into the game.
This isn't to say that couldn't be done; it could, but it would require a completely different method of hooking into the game.
132
Completely Unrelated / NaNoRenO
« on: 2008-03-16 15:45:14 »
Not been around for a while, and it occurred to me I'd never posted about NaNoRenO...
NaNoRenO is like the other various NaNo challenges, but in this case it's a challenge to "write a visual novel in a month". Most people seem to interpret that as a Renai style game for some reason, I can't possibly imagine why...
Anyway, it's sort of become a regular March thing now so as per normal I'm participating with some of my crazy friends. Some progress has been made so far...
We'll have something out by the end of the month, but if anybody's interested we did release a game last year that you can download and play ... it'll probably be reasonably fun if you like anime or renai games or both, and partially incomprehensible if you don't
If anybody does download it the game thread is here for comments/help/bug reports/etc.
ja!
NaNoRenO is like the other various NaNo challenges, but in this case it's a challenge to "write a visual novel in a month". Most people seem to interpret that as a Renai style game for some reason, I can't possibly imagine why...
Anyway, it's sort of become a regular March thing now so as per normal I'm participating with some of my crazy friends. Some progress has been made so far...
We'll have something out by the end of the month, but if anybody's interested we did release a game last year that you can download and play ... it'll probably be reasonably fun if you like anime or renai games or both, and partially incomprehensible if you don't
If anybody does download it the game thread is here for comments/help/bug reports/etc.ja!
133
Scripting and Reverse Engineering / Re: Fieldscript == TCL. There is no other way.....
« on: 2006-09-18 16:54:15 »
Read what Qhimm said ... it's probably not based on any language, really; at most it will share very, very basic syntax with a particular family of languages; mostly, block delimiters.
Also, given that it appears nothing more advanced than IF really existed, it hardly matters what syntax the original script used either; there's practically no substance there that's interesting, however it was implemented...
Also, given that it appears nothing more advanced than IF really existed, it hardly matters what syntax the original script used either; there's practically no substance there that's interesting, however it was implemented...
134
Scripting and Reverse Engineering / Re: World map viewer app
« on: 2006-09-17 15:45:29 »
In the original world map thread, Tonberry said - and I agree - that WM2 is the underwater (submarine) map, and WM3 is the snowstorm map.
It looks like they use a completely different set of texture indices, which is why everything looks wrong; I only have the textures for the main (WM0) map decoded.
It looks like they use a completely different set of texture indices, which is why everything looks wrong; I only have the textures for the main (WM0) map decoded.
135
Scripting and Reverse Engineering / World map viewer app
« on: 2006-09-17 13:59:56 »
I've uploaded a world map viewer application to my website; download it from http://www.ficedula.co.uk/f2k3/ as per normal (under "FF7 Programs", "Reeve").
See;
...it's not perfect yet, but I reckon about 90% of the textures are correct now. Controls are as per Zangan and my other 3d apps; right click to turn viewpoint around, hold left mouse button to fly forwards, press A/Z to increase or decrease height.
Essentially the entirety of the 3d mesh format is already documented here; I've just added on textures. Additional information on the file format:
In the triangle data, Unknown1 (1byte) seems to be walkmap status; I haven't investigated thoroughly, but the following values I've observed:
$23 = Deep sea (can't land highwind, water spray when flying low)
$22 = No sea spray from highwind, still can't land
$21 = No sea spray from highwind, still can't land
$20 = No sea spray, can land & walk
It may not be a simple bitmask, since $22 and $21 give the same results (I'd hoped that the lowest bit was "show spray", but apparently not.) I rather suspect at least some bits in this variable will control which chocobos can traverse the tile, too (which means figuring this out could be tedious, you might have to fudge some values, and then try every chocobo types plus vehicle type over that tile...)
The second Unknown field (2 bytes) is texture; the lower 9 bits contain a texture number (0-511, but only 0-281 appear to be used). The text files in the Reeve download show how each number maps to one (or more) .TEX files within WORLD_US.LGP. The upper bits are something to do with texture coordinate mapping; 90% of the textures work fine if you ignore them, but I'm hoping the ones that look wrong in my viewer will be due to these bits, which I don't do anything with, yet. It's most obvious on the "rocky" tiles, such as around Mideel and Midgar, which look rubbish and have muddy green patches on them.
(The viewing distance is currently rubbish in my app; this I know about.)
See;
...it's not perfect yet, but I reckon about 90% of the textures are correct now. Controls are as per Zangan and my other 3d apps; right click to turn viewpoint around, hold left mouse button to fly forwards, press A/Z to increase or decrease height.
Essentially the entirety of the 3d mesh format is already documented here; I've just added on textures. Additional information on the file format:
In the triangle data, Unknown1 (1byte) seems to be walkmap status; I haven't investigated thoroughly, but the following values I've observed:
$23 = Deep sea (can't land highwind, water spray when flying low)
$22 = No sea spray from highwind, still can't land
$21 = No sea spray from highwind, still can't land
$20 = No sea spray, can land & walk
It may not be a simple bitmask, since $22 and $21 give the same results (I'd hoped that the lowest bit was "show spray", but apparently not.) I rather suspect at least some bits in this variable will control which chocobos can traverse the tile, too (which means figuring this out could be tedious, you might have to fudge some values, and then try every chocobo types plus vehicle type over that tile...)
The second Unknown field (2 bytes) is texture; the lower 9 bits contain a texture number (0-511, but only 0-281 appear to be used). The text files in the Reeve download show how each number maps to one (or more) .TEX files within WORLD_US.LGP. The upper bits are something to do with texture coordinate mapping; 90% of the textures work fine if you ignore them, but I'm hoping the ones that look wrong in my viewer will be due to these bits, which I don't do anything with, yet. It's most obvious on the "rocky" tiles, such as around Mideel and Midgar, which look rubbish and have muddy green patches on them.
(The viewing distance is currently rubbish in my app; this I know about.)
136
Completely Unrelated / Re: What work do you do?
« on: 2006-05-23 21:11:39 »Is that like SAP but better (Well I could do better stock control in my head than sap but you get the idea)?
Yeah, not too far off. General business management software, including stock control, although we specialise in mail order processing. I've never seen SAP (I presume that's a good thing from the comments...) although I assume that naturally our product is better
Incidentally, I'm hiring at the moment, so if there's any Delphi developers need a job in East/North-east England, drop me a line...
</advert>
137
Completely Unrelated / Re: What work do you do?
« on: 2006-05-23 19:15:56 »
If I wanted to be different I could claim I'm a manager, but really I'm a programmer ;)Â Officially, Head of Development for Keystone Software Development, while technically that means I'm in charge of the other programmers and spend time arguing with our customers over how much development costs, I thankfully also spend a lot of my time programming - almost entirely in Delphi.
The chances are reasonably good that if you live in the UK you've bought/drank/eaten a product from a company using our software - particularly if you drink tea - but you probably don't know it...
The chances are reasonably good that if you live in the UK you've bought/drank/eaten a product from a company using our software - particularly if you drink tea
- but you probably don't know it...
138
Completely Unrelated / Re: Happy birthday Qhimm & ficedula!
« on: 2006-05-21 21:38:39 »
Do we actually have the same birthday? How odd.
(Well, not that odd, I guess, given the birthday paradox they teach you in maths...!)
Luckily despite my advanced years I'm still the youngest person in my office at work (although it would be quite odd if that changed without us hiring anybody else, thinking about it...)
(Well, not that odd, I guess, given the birthday paradox they teach you in maths...!)
Luckily despite my advanced years I'm still the youngest person in my office at work (although it would be quite odd if that changed without us hiring anybody else, thinking about it...)
139
Completely Unrelated / Re: Sony bites Nintendo's style, chokes on the seed
« on: 2006-05-09 22:31:56 »
Yeah, the figures are just for the entertainment divisions.
Of course, in the case of MS, they're (still) losing money on the xbox/xbox360, so my personal ebay account makes more profit than they do. Still, you're right: backed by Microsoft's rather large bank account, they can afford to do so in order to gain market share, and then ... in theory ... start ramping up profit later on in the console lifecycle.
Nintendo, to some extent, don't care so much about market share: they're making larger profits off their console than anybody else, and the fact that Microsoft is shipping more units doesn't really matter when the more N ship, the more they make, but the more MS ship, the more they lose... Also, Nintendo really are aiming at a somewhat different market to MS/Sony - it's not just marketing bullshit - so they're somewhat insulated from any alleged console war.
Sony is the company I'm interested to see whether they'll manage ... well, not to survive, I don't see them disappearing ... but they seem rather vulnerable at the moment. They sold something in the region of 6x more consoles than anybody else last time around (PS2), and were able to start pulling in profit towards the end of its lifecycle, if not so much as Nintendo. But this time around, MS has got their console out first, and it's cheaper; that's kind of the opposite position to last time when the xbox was the expensive late arrival...
(And yes, to belatedly answer the topic title, I did find it immensely amusing that after dismissing the Nintendo controller as gimmicky, Sony suddenly pull a motion sensitive controlled out of their arse for E3. Hmmm.)
Of course, in the case of MS, they're (still) losing money on the xbox/xbox360, so my personal ebay account makes more profit than they do. Still, you're right: backed by Microsoft's rather large bank account, they can afford to do so in order to gain market share, and then ... in theory ... start ramping up profit later on in the console lifecycle.
Nintendo, to some extent, don't care so much about market share: they're making larger profits off their console than anybody else, and the fact that Microsoft is shipping more units doesn't really matter when the more N ship, the more they make, but the more MS ship, the more they lose... Also, Nintendo really are aiming at a somewhat different market to MS/Sony - it's not just marketing bullshit - so they're somewhat insulated from any alleged console war.
Sony is the company I'm interested to see whether they'll manage ... well, not to survive, I don't see them disappearing ... but they seem rather vulnerable at the moment. They sold something in the region of 6x more consoles than anybody else last time around (PS2), and were able to start pulling in profit towards the end of its lifecycle, if not so much as Nintendo. But this time around, MS has got their console out first, and it's cheaper; that's kind of the opposite position to last time when the xbox was the expensive late arrival...
(And yes, to belatedly answer the topic title, I did find it immensely amusing that after dismissing the Nintendo controller as gimmicky, Sony suddenly pull a motion sensitive controlled out of their arse for E3. Hmmm.)
140
Completely Unrelated / Re: Sony bites Nintendo's style, chokes on the seed
« on: 2006-05-09 19:37:17 »
Yesh i was thinking the same thing and thus fully agree with your statement. The thing is.. If nintendo doesn't survive this generation of console gaming, what'll happen to the console gaming industry?
Given that Nintendo was making the biggest profit of all three console manufacturers from the last round of console gaming, with the alleged "failure" of the 'cube ... the question you should really be asking is: if the Revolution/Wii actually takes off big time, how much trouble do you think that puts Sony in?
141
Completely Unrelated / Small C++ Test.
« on: 2006-04-29 14:45:19 »Quote
Incidentally, do you think that programmer would have coded the same way after taking this test?
In my mind, there are two kinds of programmers: The sort that have to be hit by a brick in order to remember something, and the sort that have to be hit by a big brick.
The first impression many programmers have on seeing information such as that presented in the test (I don't exclude myself from this) is "Whoa, cool! I'll be a good little programmer and when I use it I'll make sure to test that it does what I want it to!". And then go away satisfied that they've got the point - test your code!
Really, of course, the point is "Don't fucking do this!", but the innate coolness of an Interesting Feature prevents people from getting that. I know generally people learn better when they find things out themselves rather than being just taught, but that seems dangerous with programmers - most programmers (again, probably including myself) think they're better than they really are
I like to spell it out, preferably in big comments in the code/source repository/office memo:USE THIS FEATURE AND I WILL HUNT YOU DOWN AND HURT YOU
(Once that's understood, sure, it's fun to have a discussion about these wacky features. I just like to get the line about hurting people in first.)
142
Completely Unrelated / Small C++ Test.
« on: 2006-04-27 09:55:10 »
My point is that teaching someone that pointer arithmetic is possible in C++ is a good point to make, but not also teaching them that it's undefined except under some very specific purposes is dangerous; you wouldn't want people to go away with the idea that "hey, we can perform all sorts of arithmetic on pointers, cool!". Or at least, you also want them to know: except in these cases, doing it may or may not work and we can't be sure.
Giving somebody the tools to shoot their own foot off is often desirable, but it's nice to mention how the safety works at the same time
Same sort of idea applies with the pre-post increment operators: in my mind, the most important point to make with these under virtually any circumstances is that once you use two or more on the same variable between sequence points, the results are undefined. Not "well, it actually only does it once", but literally undefined.
(I should probably mention that the reason I feel so strongly about this is I'm currently porting our code base at work from Win32 to .NET and I've been bitten a few times by code where the person who wrote it just checked "does it work on the compiler I'm using", rather than "is this meant to work at all".)
The main reason I'm mentioning funky pointers containing non-address information is that, hey, I find that information kind of cool - how many people thought pointers were always just integers, a raw 'count' of bytes? It's sort of enlightening to realise "well, my PC does that, but..."
It's yet another thing I see people assuming all over the place, "well, pointers are just integers, right? I can just convert it to an integer and back again and it's just an address in memory..." - ie. they know enough to make it work some of the time...
Giving somebody the tools to shoot their own foot off is often desirable, but it's nice to mention how the safety works at the same time
Same sort of idea applies with the pre-post increment operators: in my mind, the most important point to make with these under virtually any circumstances is that once you use two or more on the same variable between sequence points, the results are undefined. Not "well, it actually only does it once", but literally undefined.
(I should probably mention that the reason I feel so strongly about this is I'm currently porting our code base at work from Win32 to .NET and I've been bitten a few times by code where the person who wrote it just checked "does it work on the compiler I'm using", rather than "is this meant to work at all".)
The main reason I'm mentioning funky pointers containing non-address information is that, hey, I find that information kind of cool - how many people thought pointers were always just integers, a raw 'count' of bytes? It's sort of enlightening to realise "well, my PC does that, but..."
It's yet another thing I see people assuming all over the place, "well, pointers are just integers, right? I can just convert it to an integer and back again and it's just an address in memory..." - ie. they know enough to make it work some of the time...
There are two intentions here:144
Completely Unrelated / Small C++ Test.
« on: 2006-04-26 21:53:20 »Quote from: odo324
Quote from: ficedulaActually, the answer to (1), (6) and (7) is: completely undefined.
Com'on! This is just for fun...
Sure, just remember that what happens is totally compiler dependent
Spoiler: show
145
Completely Unrelated / Small C++ Test.
« on: 2006-04-26 16:55:49 »
Actually, the answer to (1), (6) and (7) is: completely undefined. The compiler could return 42 every time, shoot your pet dog, or cause the computer to blow up: all would be valid responses according to the C++ specification.
Spoiler: show
146
Scripting and Reverse Engineering / GNAT: Is the compiler doing a good job?
« on: 2005-11-27 21:28:06 »
I don't really understand SPARC syntax, but something's certainly up, because on any of the compilers I normally work with (nothing to do with Ada, of course), I'd expect something like the following to be generated for both of those procedures (Intel x86 syntax, as if it matters!)
Or, possibly, if the compiler had to play it safe:
They aren't functions, none of the values you're computing get returned, nor (as far as I can see!) are they affecting global state, so I'd expect the compiler to optimise them out totally.
I can think of a few explanations for the code you found;
1) I've misunderstood how Ada works totally. If that were Delphi code I'd expect something like the above; it's all local variables, after all...
1a) I've not misunderstood how Ada works totally, but there's some bizarre language rules particular to Ada that disallow the types of optimisation I'm thinking of.
2) You turned (some?) optimisation off for this test ... which would be kind of a problem if your paper is on testing GNAT's optimisation ability!
3) GNAT really isn't that good at optimising code.
I wouldn't like to guess which, since it's hardly my area of expertise...
Code: [Select]
Or, possibly, if the compiler had to play it safe:
Code: [Select]
RET
They aren't functions, none of the values you're computing get returned, nor (as far as I can see!) are they affecting global state, so I'd expect the compiler to optimise them out totally.
I can think of a few explanations for the code you found;
1) I've misunderstood how Ada works totally. If that were Delphi code I'd expect something like the above; it's all local variables, after all...
1a) I've not misunderstood how Ada works totally, but there's some bizarre language rules particular to Ada that disallow the types of optimisation I'm thinking of.
2) You turned (some?) optimisation off for this test ... which would be kind of a problem if your paper is on testing GNAT's optimisation ability!
3) GNAT really isn't that good at optimising code.
I wouldn't like to guess which, since it's hardly my area of expertise...
147
Archive / Enemy Attack Data [Split from Skillster's Hardcode Mode]
« on: 2005-11-10 22:00:23 »
Refer to Terrence's Battle Mechanics document on Gamefaqs. Attack "types" (cut, punch...) are actually just elements. Therefore the element is a 2-byte value, containing up to 16 possible elements (well, 15+hidden, according to the Battle Mechanics).
148
Scripting and Reverse Engineering / Render error
« on: 2005-11-03 20:24:48 »
That's called backface culling; and I'm not sure whether it's enabled by default or not. In any case, you can disable it using glDisable as per normal, or control the face winding with glCullFace, IIRC.
...but I'm not sure if it would produce those effects, anyway. Possibly something to do with the near Z plane being set too close to the camera?
...but I'm not sure if it would produce those effects, anyway. Possibly something to do with the near Z plane being set too close to the camera?
149
Scripting and Reverse Engineering / 3d drawing order
« on: 2005-11-02 16:44:21 »
Yep; I already had a flash2advance cartridge for my GBA, so originally I was using Wifime to boot the DS from the cartridge. I got tired of rewriting the cartridge every time, though, so then I've flashed the firmware on the DS to remove the signature checks; now I can boot the code directly over Wifime. The DS wifi bounty is nearly complete, so soon we'll have a TCP/IP stack on it...
150
Scripting and Reverse Engineering / 3d drawing order
« on: 2005-11-02 06:51:08 »
The assumption I'm objecting to, really (partly because I see it among the developers at work too) is that you should make some changes "because it'll make the code quicker" even though you don't know whether it will make the code quicker! Hence the whole premature optimisation malarky. Rather than wasting time guessing which bits need to be made faster, it's preferable to get it working and then benchmark.
(How could using an integer zbuffer make it slower? Well, quite apart from the fact that if you want maximum speed, you'd later convert it back to floats to use 3dnow or SSE, do you know for sure what the overhead for converting all the incoming data from floats would be?)
I still have memories of the time I optimised all our string parsing code at work only to find out it wasn't the bottleneck after all and it was the database causing the slowdown ... not good.
Cyberman: ARM7+9 says Nintendo DS to me...
(How could using an integer zbuffer make it slower? Well, quite apart from the fact that if you want maximum speed, you'd later convert it back to floats to use 3dnow or SSE, do you know for sure what the overhead for converting all the incoming data from floats would be?)
I still have memories of the time I optimised all our string parsing code at work only to find out it wasn't the bottleneck after all and it was the database causing the slowdown ... not good.
Cyberman: ARM7+9 says Nintendo DS to me...