Forum Index | FAQ | New User | Login | Search

Make a New PostPrevious ThreadView All ThreadsNext Thread*Show in Threaded Mode


SubjectAnother quick (OT) program query new Reply to this message
Posted byfinaldave
Posted on11/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_variable
for reading in my_variable

You 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...



SubjectRe: Another quick (OT) program query new Reply to this message
Posted byR. Belmont
Posted on11/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).





SubjectRe: Another quick (OT) program query new Reply to this message
Posted byfinaldave
Posted on11/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...



SubjectRe: Another quick (OT) program query new Reply to this message
Posted byBart T.
Posted on11/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


SubjectRe: Another quick (OT) program query new Reply to this message
Posted byfinaldave
Posted on11/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...



SubjectRe: Another quick (OT) program query new Reply to this message
Posted byR. Belmont
Posted on11/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).





SubjectMultiple .cpp problem new Reply to this message
Posted byfinaldave
Posted on11/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... patching
sys12A8.tmp(95047) : error: Could not pair all HI relocs with LOs
make[1]: *** [system_lib.o] Error 1
make: *** [system.a] Error 2

Which 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...



SubjectRe: Multiple .cpp problem Reply to this message
Posted bysmf
Posted on11/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





SubjectRe: Multiple .cpp problem new Reply to this message
Posted byfinaldave
Posted on11/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...



SubjectOH YOU'RE fucking going to love this new Reply to this message
Posted byfinaldave
Posted on11/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.
> >
> > smf


I 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...



SubjectRe: OH YOU'RE fucking going to love this new Reply to this message
Posted byBart T.
Posted on11/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


SubjectRe: OH YOU'RE fucking going to love this new Reply to this message
Posted byStroff
Posted on11/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 guys
2. stick with objective arguments (i.e. total compile time, namespace issues); anything resembling a religious argument will get you shut down
3. if at all possible, show proof of concept of something better, and do it in your own time


SubjectRe: OH YOU'RE fucking going to love this new Reply to this message
Posted byR. Belmont
Posted on11/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 :-)





SubjectRe: OH YOU'RE fucking going to love this new Reply to this message
Posted bysmf
Posted on11/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





SubjectRe: OH YOU'RE fucking going to love this new Reply to this message
Posted byfinaldave
Posted on11/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 down

Will 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...



SubjectActually...! new Reply to this message
Posted byfinaldave
Posted on11/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 unlikely

And 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...



SubjectRe: OH YOU'RE fucking going to love this new Reply to this message
Posted bysmf
Posted on11/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





SubjectRe: OH YOU'RE fucking going to love this new Reply to this message
Posted bythe_flip
Posted on11/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.






SubjectRe: OH YOU'RE fucking going to love this new Reply to this message
Posted byfinaldave
Posted on11/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...



SubjectThe resolution (i hope!) new Reply to this message
Posted byfinaldave
Posted on11/19/03 08:44 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.


Okay - just a quick epilogue to this little dispute: I went to see the MD (sounds a bit bad however it actually wasn't: you see he'd told me specifically to come to him if I found the other programmers were being too restrictive about anything), and showed him a document I had printed out which carefully went through every point this guy had come out with (the malloc thing, the printf thing, the dependancy stuff) and showed him a clear record of why I wasn't doing what this guy claimed.

Today we had another meeting - same guys only with the MD there as well, and went over the points in the Doc I had written - it went MUCH better than Friday and they asked if everything was cool now, and we said we thought yeah everything had been sorted out.

As well as that Document, I did have one other line of defence(! yeah it really did feel like a weapon!) in my bag, which was another document I printed up explaining why compiling everything in one go was such a bad idea, dependancy, compile times being 10 - 50(!) times higher, a copy of the compiler bug, namespace (thanks for the help!)... however I didn't have to use it thank god.

It would only have made the guy even more confrontation anyway, it was only there to use if the guy carried on with his crazy bollocks 'Dave is causing a Sony Technical violation with his code' stance.

However I've sent a copy of ALL the docs to myself on the e-mail system, so they are clearly dated. If they get some massive compiler breakdown and try to make me the fall guy again, I can defend myself and prove that I illustrated the problem to him back in November.


> 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
>


You learn something old everyday...



SubjectRe: OH YOU'RE fucking going to love this new Reply to this message
Posted byKayamon
Posted on11/19/03 02:59 PM



> for example that I was using the function malloc()
> in the game code instead of the companies memory
> allocation functions, which isn't true

One point which may or may not be relevant - sometimes libc functions (e.g. printf) can call malloc themselves internally, which is why their use is sometimes frowned upon.

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.

I can't imagine this'd cause a TRC violation in any way - I think that's just someone trying to wind you up ;-)


SubjectRe: OH YOU'RE fucking going to love this new Reply to this message
Posted byR. Belmont
Posted on11/19/03 10:27 PM



> 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.





SubjectRe: OH YOU'RE fucking going to love this new Reply to this message
Posted byfinaldave
Posted on11/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 recall

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?


You learn something old everyday...



SubjectRe: OH YOU'RE fucking going to love this new Reply to this message
Posted byR. Belmont
Posted on11/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 recall

There'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).





SubjectRe: OH YOU'RE fucking going to love this new Reply to this message
Posted byectordxm
Posted on12/07/03 07:07 AM



Quite a few Gamecube games print out debugging TTY stuff too. How I know this I am not going to tell you atm :)




Previous ThreadView All ThreadsNext Thread*Show in Threaded Mode