Welcome to Emulationworld

 Forum Index | FAQ | New User | Login | Search

 Subject Another quick (OT) program query Posted by finaldave Posted on 11/07/03 08:34 AM In PS2/XBox/GC development, are the C++ >> file stream stuff usually used for loading files?e.g.file >> my_variablefor reading in my_variableYou see it is used all the time on the code I'm working on, but I always preferred static buffer reads myself, I could never stand all the cout/cin weird stuff. I would have though C style loading suited consoles more. What do you think?You learn something old everyday...

 Subject Re: Another quick (OT) program query Posted by R. Belmont Posted on 11/07/03 01:19 PM I've never seen iostreams used in a console game. Each system has specific I/O calls for the disc and memory card (or Win32 CreateFile() and friends on the Xbox).

 Subject Re: Another quick (OT) program query Posted by finaldave Posted on 11/07/03 01:31 PM > I've never seen iostreams used in a console game. Each system has specific I/O> calls for the disc and memory card (or Win32 CreateFile() and friends on the> Xbox).> They are aren't exactly iostreams per say, they just overload the >> operator a bit like them and have methods for loading into 8, 16 32, 64 and 128-bit values.Good, bad, ugly?By the way isn't it cool that XBox programming is exactly like PC DirectX 8 programming (only without the silly GDI - I'm quite chuffed by the look of it! ;)You learn something old everyday...

 Subject Re: Another quick (OT) program query Posted by Bart T. Posted on 11/07/03 04:34 PM > They are aren't exactly iostreams per say, they just overload the >> operator a> bit like them and have methods for loading into 8, 16 32, 64 and 128-bit values.> > Good, bad, ugly?In the end, it's just syntactical sugar. I personally thing operator overloading sucks, but to each his own.> By the way isn't it cool that XBox programming is exactly like PC DirectX 8> programming (only without the silly GDI - I'm quite chuffed by the look of it!> ;)Does MS disallow XBox games from accessing the hardware directly? If everything is abstracted through APIs like DirectX, wouldn't a CPU switch for XBox 2 be more feasible?I still think the announcement about MS licensing technology from IBM is too vague to tell whether they're actually going to ditch X86.----Bart

 Subject Re: Another quick (OT) program query Posted by finaldave Posted on 11/07/03 10:13 PM > > They are aren't exactly iostreams per say, they just overload the >> operator> a> > bit like them and have methods for loading into 8, 16 32, 64 and 128-bit> values.> > > > Good, bad, ugly?> > In the end, it's just syntactical sugar. I personally thing operator overloading> sucks, but to each his own.> > > By the way isn't it cool that XBox programming is exactly like PC DirectX 8> > programming (only without the silly GDI - I'm quite chuffed by the look of it!> > ;)> > Does MS disallow XBox games from accessing the hardware directly?No idea, but I think everyone uses DirectX 8. Aren't Pixel Shaders supported in DX8 too? If everything> is abstracted through APIs like DirectX, wouldn't a CPU switch for XBox 2 be> more feasible?Yep I guess so - for the first time I think MS are going to beat Sony at that one... my god, what am I saying - MS have done something... right!> > I still think the announcement about MS licensing technology from IBM is too> vague to tell whether they're actually going to ditch X86.> > > ----> Bart> You learn something old everyday...

 Subject Re: Another quick (OT) program query Posted by R. Belmont Posted on 11/09/03 11:33 AM You're specifically disallowed from hitting any hardware registers. And yes, DX8 has "1.1" pixel and vertex shaders - the XGPU is essentially a "DX8.0 part" (GF3 with some GF4 features, in this case).

 Subject Multiple .cpp problem Posted by finaldave Posted on 11/12/03 06:35 AM > You're specifically disallowed from hitting any hardware registers. And yes,> DX8 has "1.1" pixel and vertex shaders - the XGPU is essentially a "DX8.0 part"> (GF3 with some GF4 features, in this case).> Sorry to bring this up (again)... it just that I'm in a bit of a mess on this one!:Remember I said that this PS2 project I was working on was a bit strange in that they just #included every CPP file into on big file and then compiled that?Well anyway I've been told in no undercertain terms that that is the way it is staying, because compiling the cpps seperately would increase the compilation times (which I REALLY cannot understand, because everytime I change one CPP file I have to recompile about 12 others as well).But now I have this problem: when I add in two lines (which can be anything - e.g. printf("test");), I get this error message and it won't compile:ps2eeas version 1.9.25.758 @ "Z:\usr\local\sce\ee\gcc\ee\bin\ps2eeas.exe"Second pass... patchingsys12A8.tmp(95047) : error: Could not pair all HI relocs with LOsmake[1]: *** [system_lib.o] Error 1make: *** [system.a] Error 2Which I take out the print("test"); the problem goes away!But I can't add any more lines of code to the project![Update - hmm, weird - if I add 3 lines of code the the project, it compiles fine?]I mean the single .cpp file is about 35k in total, and the token namespace will be massive - I'm thinking it's no wonder the compiler is struggling. What happens if we are 2 days away from mastering and this problem comes back?Do you guys agree with me that this looks very much like it's a consequence of having all the CPPs in one file?If so what should I do - everyone got quite defensive last time I tried to persuade them to alter the makefile, and I've been asked to work on something which I can't do because of these compiler errors?Should I attempt to change the entire makefile locally? I get the feeling that would REALLY piss them off so I'm not keen...You learn something old everyday...

 Subject Re: Multiple .cpp problem Posted by smf Posted on 11/12/03 02:31 PM I imagine splitting the project up is going to be difficult for two reasons:1. you're going to have to write .h's for each .cpp.2. it sounds like they'll have your balls.You could do it and show them how much quicker it is ( or if it's slower then don't ever mention it again ). Unfortunately because of the randomness of the problem you are getting you are unlikely to know if splitting it up does actually make the problem go away, it might even make it worse.smf

 Subject Re: Multiple .cpp problem Posted by finaldave Posted on 11/13/03 11:53 AM > I imagine splitting the project up is going to be difficult for two reasons:> 1. you're going to have to write .h's for each .cpp.Actually they already have .hs for each cpp, they #include all of those in a big .h as well> 2. it sounds like they'll have your balls.Yep!> You could do it and show them how much quicker it is ( or if it's slower then> don't ever mention it again ). Unfortunately because of the randomness of the> problem you are getting you are unlikely to know if splitting it up does> actually make the problem go away, it might even make it worse.> > smf> You learn something old everyday...

 Subject OH YOU'RE fucking going to love this Posted by finaldave Posted on 11/14/03 10:06 AM > > I imagine splitting the project up is going to be difficult for two reasons:> > 1. you're going to have to write .h's for each .cpp.> > Actually they already have .hs for each cpp, they #include all of those in a big> .h as well> > > 2. it sounds like they'll have your balls.> > Yep!> > > You could do it and show them how much quicker it is ( or if it's slower then> > don't ever mention it again ). Unfortunately because of the randomness of the> > problem you are getting you are unlikely to know if splitting it up does> > actually make the problem go away, it might even make it worse.> > > > smfI was just called to the Senior Producers office with the other two programmers, and it turns out there a bit of backstabbing going on! Actually from just one of them - basically he's been e-mailling him and saying "Dave causing a lot of friction about a number of topics" and listed them!Haha! and I didn't even do anything - I just commented it wasn't very stable, and pointed out the compile bug!The comments which came out where stuff like this"Dave, basically we are quite concerned - it's clear you are a very talented programmer, however it's a little bit insulting to these programmers here when you come along after only a couple of weeks and dont trust the advice of our programmers"Anyway, during the meeting I basically figured RIIIGHT, sod it! - and the gloves came off, I pointed out to the Senior Producer that the compilation technique the other guys were forcing me to use was (A) crazily slow especially on my machine! and (B) inherently very unstable for GCC because I'd had a load of unexplained fatal compilation errors![I mean christ, they'll be two days away from mastering and the compiler will fall apart!]He looked a bit shocked actually at that point - he kind of stopped in his tracks and said "guys um, I'd like to address this - is there something unstable about the way we are building the game?"Quite a freaky day overall! What an arse!You learn something old everyday...

 Subject Re: OH YOU'RE fucking going to love this Posted by Bart T. Posted on 11/14/03 12:24 PM > The comments which came out where stuff like this> "Dave, basically we are quite concerned - it's clear you are a very talented> programmer, however it's a little bit insulting to these programmers here when> you come along after only a couple of weeks and dont trust the advice of our> programmers"Hehe, poor Dave. I hope none of your co-workers frequent this site ;) > He looked a bit shocked actually at that point - he kind of stopped in his> tracks and said "guys um, I'd like to address this - is there something unstable> about the way we are building the game?"Have they given an actual explanation as to why they're doing it the way they are (besides that it's "faster")? I still don't see the point unless they're hoping for better optimization (do they declare all functions as static?), in which case they're still wasting their time with this.----Bart

 Subject Re: OH YOU'RE fucking going to love this Posted by Stroff Posted on 11/14/03 02:18 PM The only plausible reason I can think of for this approach, is that the people involved aren't comfortable with makefiles, and don't want to admit weakness. There are plenty of folk spoiled by IDEs in this camp.If you pull in all your .c files via #includes, what this buys you is that you can use a single makefile, never have to add new modules to it.On the downside, you completely screw your namespace; you can't use private variables or private helper functions - everything is effectively global.And the compile time will be horrible, of course.Anyway, my advice to you is:1. avoid being confrontational; for better or worse, you have to work with these guys2. stick with objective arguments (i.e. total compile time, namespace issues); anything resembling a religious argument will get you shut down3. if at all possible, show proof of concept of something better, and do it in your own time

 Subject Re: OH YOU'RE fucking going to love this Posted by R. Belmont Posted on 11/15/03 00:41 AM I agree with everything Phil says. We hire guys like that all the time. You'd think colleges don't have Unix anymore, and I know that's not true :-)

 Subject Re: OH YOU'RE fucking going to love this Posted by smf Posted on 11/15/03 05:16 AM > you can't use private> variables or private helper functions - everything is effectively global.That borders on religious though. You can have the private variables & helper functions, you just don't have any way for the compiler to enforce it. A programmer that is going to #include every .c file, is going to use that to show weakness in the person that uses the private stuff ( i.e. you, because he wouldn't be so stupid & you obviously would or you wouldn't have mentioned it ).Also build times are only really a problem if you write code that has bugs in it, so if you're worried about it then "obviously" your code isn't as good as the people that don't care.Sounds like this guy is running scared ( well unless you really were a pain in the arse to him and didn't realise ), which means you'll take the fall if anything goes wrong. Especially if the delays in the project are due to you demanding the build system changes.People never want to hear that they are wrong, especially in front of their boss. It's better to prove what you are saying is right to yourself first, instead of having an all out argument. Until you have an easy to use build system ( list of source files go in one end, makefile with dependancies comes out the other ) then you're going to get resistance to the idea. Management will probably see this as a waste of resources, so it has to be done in your own time. If you handle problems like that then everyone would win.The worst time I ever had was with someone that was dyslexic, so he really didn't care at all about code readability. In fact by making it as unreadable as possible he brought you down to his level. The classic is commenting out lines of code that aren't needed ( including multiple page long functions ) and then checking them in to source control "just in case". Find in files doesn't care whether the code is #if'd or commented out & any work you do on the file requires you to read the entire thing to work out just which version you're supposed to change ( or in my case keep, as I'll dump all the dead wood ).smf

 Subject Re: OH YOU'RE fucking going to love this Posted by finaldave Posted on 11/15/03 06:59 AM > The only plausible reason I can think of for this approach, is that the people> involved aren't comfortable with makefiles, and don't want to admit weakness. > There are plenty of folk spoiled by IDEs in this camp.> > If you pull in all your .c files via #includes, what this buys you is that you> can use a single makefile, never have to add new modules to it.> > On the downside, you completely screw your namespace; you can't use private> variables or private helper functions - everything is effectively global.> > And the compile time will be horrible, of course.> > Anyway, my advice to you is:> 1. avoid being confrontational; for better or worse, you have to work with these> guys> 2. stick with objective arguments (i.e. total compile time, namespace issues);> anything resembling a religious argument will get you shut downWill do - I think what I've decided to do is make a written dated record of what I was accused of at this meeting by this guy, because there were a couple of allegations that were simply false - for example that I was using the function malloc() in the game code instead of the companies memory allocation functions, which isn't true, and by doing that I was affecting the Sony Technical Requirements and the game would fail. (What's it called? I could do with putting the official name on this Doc, is it the Sony T.R.I., or T.R.C. or something?)I could note down in the same document the thigns about the #including, compile time, namespace issues, the resultant compiler crash output with a date etc.> 3. if at all possible, show proof of concept of something better, and do it in> your own time> You learn something old everyday...

 Subject Actually...! Posted by finaldave Posted on 11/15/03 04:18 PM > > The comments which came out where stuff like this> > "Dave, basically we are quite concerned - it's clear you are a very talented> > programmer, however it's a little bit insulting to these programmers here when> > you come along after only a couple of weeks and dont trust the advice of our> > programmers"> > Hehe, poor Dave. I hope none of your co-workers frequent this site ;) Actually it's quite surreal because although none of them visit Retrogames, a couple have copies of Final Burn on their machine, and even DGen as well even though I pointed out it's v. old and crap! Most of them are into emulation and stuff!Though not this weird guy who's come out with all these accusations - he's not into emulation afaik, he's just into... well being a bit of a prick really and trying to get me sacked!> > > He looked a bit shocked actually at that point - he kind of stopped in his> > tracks and said "guys um, I'd like to address this - is there something> unstable> > about the way we are building the game?"> > Have they given an actual explanation as to why they're doing it the way they> are (besides that it's "faster")? I still don't see the point unless they're> hoping for better optimization (do they declare all functions as static?), in> which case they're still wasting their time with this.They still claim it's 'faster', however it's clearly not because of the need for almost total rebuilds.Maybe they just don't 'get' incremental compilation, though that seems unlikelyAnd no - everything is C++, nothing static in sight. The mind boggles how they managed to get into this state where they quite genuinely believe this is the only decent way to compile for PS2.You learn something old everyday...

 Subject Re: OH YOU'RE fucking going to love this Posted by smf Posted on 11/15/03 07:19 PM > for example that I was using the function> malloc() in the game code instead of the companies memory allocation functions,Thats what source code control is for, always ask people nicely to point out where you make mistakes. Sometimes they might even be right.smf

 Subject Re: OH YOU'RE fucking going to love this Posted by the_flip Posted on 11/16/03 04:18 AM > I agree with everything Phil says. We hire guys like that all the time. You'd> think colleges don't have Unix anymore, and I know that's not true :-)> Except for some specialised subjects, that's all we had at the University I attended to for a development environment.

 Subject Re: OH YOU'RE fucking going to love this Posted by finaldave Posted on 11/16/03 06:40 AM > > for example that I was using the function> > malloc() in the game code instead of the companies memory allocation> functions,> > Thats what source code control is for, always ask people nicely to point out> where you make mistakes.Point taken... thing is, this guy went straight to the Senior Producer - I didn't know anything about it. He's never even uttered the word 'malloc' to me!>Sometimes they might even be right.> > smf> [PS - sorry everyone, I know I'm abusing this board a little bit and almost 'blogging' it to death! should be over soon hopefully...]You learn something old everyday...

 Subject Re: OH YOU'RE fucking going to love this Posted by finaldave Posted on 11/22/03 07:46 AM > > At our place, we have our own printf-style functions (along with lots of other> > bits of libc), so that we can control that stuff directly.> > Yeah, we do the same thing. Also allows cleanly locking out printf on> final/release builds. Lots of devs don't - if you have a T10k, boot up Jak and> Daxter on it, and watch the TTY literally dump pages and pages of detailed debug> info as you play (seen it myself on the US NTSC release, the PAL version might> be cleaner). Or more (in)famously, SCEE's Porsche Challenge on PS1 prints out> something like "USER IS A BLOODY GIT" if you don't finish the race.> Ha! I thought T10k couldn't play commercial games though?Actually though maybe there are some boot flags you can set to make it act like a real PS2... can't recallSo TTY output isn't even a Sony TRC violation anyway (not that I ever left TTY output in in the first place, %!$£!)?...or Jak and Daxter wouldn't have shipped?You learn something old everyday...  Subject Re: OH YOU'RE fucking going to love this Posted by R. Belmont Posted on 11/22/03 12:37 PM > Ha! I thought T10k couldn't play commercial games though?> Actually though maybe there are some boot flags you can set to make it act like> a real PS2... can't recallThere's two ways - you can pass special boot flags, or you can write a little program that runs from your devkit and "bootstraps" the disc.> So TTY output isn't even a Sony TRC violation anyway (not that I ever left TTY> output in in the first place, %!$£!)?> ...or Jak and Daxter wouldn't have shipped?TRC enforcement is a bit "flexible" for first and second party titles. (This is true for Microsoft also - I haven't noticed any obvious violations in Nintendo in-house games).