gamedevlists-consoles Mailing List for gamedev (Page 3)
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-consoles — List for discussing game development on consoles like the PS2 and XBox
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(28) |
Nov
(12) |
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
|
Mar
(16) |
Apr
|
May
(5) |
Jun
|
Jul
(18) |
Aug
(6) |
Sep
|
Oct
(3) |
Nov
(4) |
Dec
|
| 2003 |
Jan
(4) |
Feb
(63) |
Mar
(1) |
Apr
(15) |
May
(16) |
Jun
(6) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(6) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(6) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Ben C. <be...@gu...> - 2003-04-13 17:18:04
|
On Sunday, April 13, 2003, 5:58:51 PM, someone wrote:
[snip]
> But what I really got out of the discussion was a need to question the
> ancient wisdom that you can't stream audio and data at the same time
> (you'd think GTA3 would have caused me to do that, but I'm kinda slow
> sometimes).
Oh, definitely - with a decent IOP-side library handling your CD
reads, you can stream quite a decent amount - Battle Engine Aquila has
three separate streams going during the game - music, radio message
speech and background texture loading.
The only major gotchas I remember were the necessity to add priorities
to the loading system, and allow operations to be interrupted, so a
large load (of, say, a 512x512 texture) could be suspended briefly
whilst the next chunk of music was pulled in, and some code to sort
queued operations by disc position to minimise unnecessary seeks.
Oh, and we did a bit of data rearrangement to put pagable data
together on the disc, but nothing more clever than sticking all the
music, speech & texture files in roughly the same place.
--
Ben Carter - be...@gu...
---------------------------------PGP Key available on request---
"Broken mirror, a million shades of light,
the old echo fades away.
But just you and I can find the answer,
and then we can run to the end of the world."
- Small of two pieces, Xenogears
|
|
From: brian s. <pud...@po...> - 2003-04-13 16:58:54
|
Key points from the newsgroup discussion: * IOP is probably too slow to decode Vorbis, unless you use the integer-only decoder and don't plan on doing *anything* else with the IOP, in which case you might have *just* enough cycles to do it. If that sounds like fun to you, you're braver than I am. Not an inspiring prospect. * On EE, a simple port of the code gives you a Vorbis engine that consumes about 10% of CPU. Moving the some of the time-critical code to VU0 should result in significant speedups, but as far as I can tell no one has publicly released such a thing. Feasible, but requires some work unless you have 10% of your CPU budget going unused. But what I really got out of the discussion was a need to question the ancient wisdom that you can't stream audio and data at the same time (you'd think GTA3 would have caused me to do that, but I'm kinda slow sometimes). On PS2, the Multistream library looks like it can give me a pretty efficient implementation of streaming audio while streaming data. Obviously on Xbox you have so much flexibility with the hard drive that it's dead simple to do both. So the thing I need to figure out now is whether I can pull off streaming music and data simultaneously on GCN. And if not, maybe I'll end up using Vorbis there. --brian On Saturday, April 12, 2003, at 07:55 PM, J. Grant wrote: > Hi Michael, > > Out of interest what was the conclusion of this discussion? I do not > have access to sce.* newsgroups. > > Which released console titles use Ogg Vorbis steams? > > Do sound API's like Miles support Ogg Streams now? > > Cheers > > JG > > > > on the 11/04/03 19:14, Michael Pohoreski wrote: >> Check out the thread "Vorbis" on sce.dev.prog.spu >> -----Original Message----- >> From: brian sharon [mailto:pud...@po...] Sent: Friday, April >> 11, 2003 10:46 AM >> To: gam...@li... >> Subject: [GD-Consoles] anyone used Ogg Vorbis on PS2/GCN? >> http://www.xiph.org/ogg/vorbis/ >> If you have, would you mind sharing your experience, good or bad? >> --brian |
|
From: chaac <ch...@ni...> - 2003-04-13 08:20:19
|
13.4.2003 05:55:59, "J. Grant" <jg-...@jg...> wrote: >Out of interest what was the conclusion of this discussion? I do not >have access to sce.* newsgroups. > >Which released console titles use Ogg Vorbis steams? > >Do sound API's like Miles support Ogg Streams now? Atleast fmod does have oggvorbis support also for ps2. But you can't get ps2 version without official ps2 license with sony. see table at bottom of this page: http://www.fmod.org/ifmodfeatures.html - chaac |
|
From: J. G. <jg-...@jg...> - 2003-04-13 02:51:58
|
Hi Michael, Out of interest what was the conclusion of this discussion? I do not have access to sce.* newsgroups. Which released console titles use Ogg Vorbis steams? Do sound API's like Miles support Ogg Streams now? Cheers JG on the 11/04/03 19:14, Michael Pohoreski wrote: > Check out the thread "Vorbis" on sce.dev.prog.spu > > > -----Original Message----- > From: brian sharon [mailto:pud...@po...] > Sent: Friday, April 11, 2003 10:46 AM > To: gam...@li... > Subject: [GD-Consoles] anyone used Ogg Vorbis on PS2/GCN? > > > http://www.xiph.org/ogg/vorbis/ > > If you have, would you mind sharing your experience, good or bad? > > --brian > |
|
From: Michael P. <MPo...@cy...> - 2003-04-11 18:15:39
|
Check out the thread "Vorbis" on sce.dev.prog.spu -----Original Message----- From: brian sharon [mailto:pud...@po...]=20 Sent: Friday, April 11, 2003 10:46 AM To: gam...@li... Subject: [GD-Consoles] anyone used Ogg Vorbis on PS2/GCN? http://www.xiph.org/ogg/vorbis/ If you have, would you mind sharing your experience, good or bad? --brian |
|
From: brian s. <pud...@po...> - 2003-04-11 14:46:24
|
http://www.xiph.org/ogg/vorbis/ If you have, would you mind sharing your experience, good or bad? --brian |
|
From: Kromyx <jad...@co...> - 2003-03-17 12:41:40
|
Henrik Andersen <pet...@ho...> schrieb in im Newsbeitrag: b3d098$ad1$1...@ma...... > Hi! > I am a newbie in game programming for Sony Playstation PSOne. I am familiar > with game programming in c++ for windows. Which tools are used for the > playstation? Are there any open source programming tools to ease the porting > from windows to playstation? > > Thanks in advance! > Hi Henrik, there are free tools available for ps1 programming but you'll also need some hardware. there is a patched gcc (mipsgcc) version (based on 2.8x IIRC) which has some problems with the "-O3" switch if you dont patch it (increase stack size with some tool which comes with vc6 (cant remember the name). you'll further need a AR with Comm-Card (ISA) and flash it with a another firmware called "Caetla". --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.434 / Virus Database: 243 - Release Date: 25.12.02 |
|
From: <phi...@pl...> - 2003-02-28 19:11:31
|
The PS2 fp support is indeed lacking denormals, also the various NAN's. Any
calculation involving them, tends to produce 0 in the results. This in
turn, tends to hide numerically catastrophic situations. The only other
thing I'm aware of, is that the FMAC units aren't symettrical at the lowest
bit. 1 x A != A x 1. This usually isn't a problem, but could potentially
cause otherwise inexplicable cracking.
Cheers
Phil
PS In their favour, there are 10 of them, and you can run them all at the
same time.
"Jacob Turner (Core Design Ltd)"
<Ja...@Co...> To: "'gam...@li...'"
Sent by: <gam...@li...>
gam...@li...urc cc:
eforge.net Fax to:
Subject: RE: [GD-Consoles] PS2 floating point
02/28/2003 02:22 AM
Please respond to gamedevlists-consoles
The one thing I do know is that on PC (don't know about GameCube) when
floating point numbers get very small it can switch to using de-normalised
mode (I think that is the term) which gives more accuracy.
I don't think the PS2 has this mode so it tends to just set everything to
0.0.
In my experience I have had it the other way i.e. PS2 is stable and fine
but
PC goes wrong.
-----Original Message-----
From: Research (GameBrains) [mailto:res...@ga...]
Sent: 28 February 2003 05:14
To: gam...@li...
Subject: Re: [GD-Consoles] PS2 floating point
We are still looking at the problem, but it seems that calculations
resulting in small numbers are the problem. On GameCube and PC the results
are correct but on the PS2 it's not. Still a good possibility that there
is
simply a bug in our code somewhere too :-) The cool thing about
multi-platform development is a lot of times different hardware and
different compilers help you find bugs you would have never found
otherwsie....
Cheers,
Brett
----- Original Message -----
From: "J. Grant" <jg-...@jg...>
To: <gam...@li...>
Sent: Thursday, February 27, 2003 10:33 PM
Subject: Re: [GD-Consoles] PS2 floating point
> Hi Brett,
>
> Out of interest what was the problem with your implementation? I found
> that -fshort-double stopped some of the problems I was having with one
> issue when I tested some float stuff a while ago. However, if the code
> is the problem then this would not solve that.
>
> JG
>
> Research (GameBrains) wrote:
> > Gareth,
> > Found it! (moved to chapter 8 in 6th edition). Thank you very much!
> > Brett
> >
> > ----- Original Message -----
> > From: "Gareth White" <gw...@ra...>
> > To: <res...@ga...>
> > Cc: <gam...@li...>
> > Sent: Thursday, February 27, 2003 2:49 PM
> > Subject: Re: [GD-Consoles] PS2 floating point
> >
> >
> >> There are indeed subtle differences between the PS2 and the IEEE
implementation.
> >>
> >> Try the 'EE Core User's Manual' (2nd Edition), Page 77, Chapter 4
> >> 'Floating-Point Unit (FPU)', section 4.8 'IEEE 754 Compatability'
> >>
> >> Cheers.
> >>
> >> ---
> >> Gareth White - Engine Programmer - Ratbag Pty Ltd
> >> Level 8, 63 Pirie Street, Adelaide, SA, Australia, 5000
> >> Ph: +61 8 8223 5830, Fax: +61 8 8223 5746, Mob: 0403 942668
> >> http://www.ratbaggames.com/
> >>
> >> ----- Original Message -----
> >> From: "Research (GameBrains)" <res...@ga...>
> >> To: <Gam...@li...>
> >> Sent: Thursday, February 27, 2003 4:46 PM
> >> Subject: [GD-Consoles] PS2 floating point
> >>
> >>
> >> Hello,
> >> Our physics engine is experiencing some odd behavior on the PS2. We
traced it
> >> to our resting contact force calculation where sometimes it seems the
result is
> >> not quite right, but it works fine on other platforms. I don't know
if
it's an
> >> urban legend or what, but I have heard that the PS2 has some quirks
with regard
> >> to floating point numbers and so I thought I would just ask and see if
this is
> >> something I need to look at or not. If so, what are the differences
between the
> >> PS2 IEEE implementation and is there a doc describing them?
> >> Thanks,
> >> Brett
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gamedevlists-consoles mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=553
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Gamedevlists-consoles mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU3
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Gamedevlists-consoles mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=553
|
|
From: Jacob T. (C. D. Ltd) <Ja...@Co...> - 2003-02-28 10:23:46
|
The one thing I do know is that on PC (don't know about GameCube) when floating point numbers get very small it can switch to using de-normalised mode (I think that is the term) which gives more accuracy. I don't think the PS2 has this mode so it tends to just set everything to 0.0. In my experience I have had it the other way i.e. PS2 is stable and fine but PC goes wrong. -----Original Message----- From: Research (GameBrains) [mailto:res...@ga...] Sent: 28 February 2003 05:14 To: gam...@li... Subject: Re: [GD-Consoles] PS2 floating point We are still looking at the problem, but it seems that calculations resulting in small numbers are the problem. On GameCube and PC the results are correct but on the PS2 it's not. Still a good possibility that there is simply a bug in our code somewhere too :-) The cool thing about multi-platform development is a lot of times different hardware and different compilers help you find bugs you would have never found otherwsie.... Cheers, Brett ----- Original Message ----- From: "J. Grant" <jg-...@jg...> To: <gam...@li...> Sent: Thursday, February 27, 2003 10:33 PM Subject: Re: [GD-Consoles] PS2 floating point > Hi Brett, > > Out of interest what was the problem with your implementation? I found > that -fshort-double stopped some of the problems I was having with one > issue when I tested some float stuff a while ago. However, if the code > is the problem then this would not solve that. > > JG > > Research (GameBrains) wrote: > > Gareth, > > Found it! (moved to chapter 8 in 6th edition). Thank you very much! > > Brett > > > > ----- Original Message ----- > > From: "Gareth White" <gw...@ra...> > > To: <res...@ga...> > > Cc: <gam...@li...> > > Sent: Thursday, February 27, 2003 2:49 PM > > Subject: Re: [GD-Consoles] PS2 floating point > > > > > >> There are indeed subtle differences between the PS2 and the IEEE implementation. > >> > >> Try the 'EE Core User's Manual' (2nd Edition), Page 77, Chapter 4 > >> 'Floating-Point Unit (FPU)', section 4.8 'IEEE 754 Compatability' > >> > >> Cheers. > >> > >> --- > >> Gareth White - Engine Programmer - Ratbag Pty Ltd > >> Level 8, 63 Pirie Street, Adelaide, SA, Australia, 5000 > >> Ph: +61 8 8223 5830, Fax: +61 8 8223 5746, Mob: 0403 942668 > >> http://www.ratbaggames.com/ > >> > >> ----- Original Message ----- > >> From: "Research (GameBrains)" <res...@ga...> > >> To: <Gam...@li...> > >> Sent: Thursday, February 27, 2003 4:46 PM > >> Subject: [GD-Consoles] PS2 floating point > >> > >> > >> Hello, > >> Our physics engine is experiencing some odd behavior on the PS2. We traced it > >> to our resting contact force calculation where sometimes it seems the result is > >> not quite right, but it works fine on other platforms. I don't know if it's an > >> urban legend or what, but I have heard that the PS2 has some quirks with regard > >> to floating point numbers and so I thought I would just ask and see if this is > >> something I need to look at or not. If so, what are the differences between the > >> PS2 IEEE implementation and is there a doc describing them? > >> Thanks, > >> Brett > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Gamedevlists-consoles mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=553 ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Gamedevlists-consoles mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles Archives: http://sourceforge.net/mailarchive/forum.php?forum_idU3 |
|
From: Research \(GameBrains\) <res...@ga...> - 2003-02-28 05:01:38
|
We are still looking at the problem, but it seems that calculations = resulting in small numbers are the problem. On GameCube and PC the = results are correct but on the PS2 it's not. Still a good possibility = that there is simply a bug in our code somewhere too :-) The cool thing = about multi-platform development is a lot of times different hardware = and different compilers help you find bugs you would have never found = otherwsie.... Cheers, Brett ----- Original Message -----=20 From: "J. Grant" <jg-...@jg...> To: <gam...@li...> Sent: Thursday, February 27, 2003 10:33 PM Subject: Re: [GD-Consoles] PS2 floating point > Hi Brett, >=20 > Out of interest what was the problem with your implementation? I = found > that -fshort-double stopped some of the problems I was having with one > issue when I tested some float stuff a while ago. However, if the = code > is the problem then this would not solve that. >=20 > JG >=20 > Research (GameBrains) wrote: > > Gareth, > > Found it! (moved to chapter 8 in 6th edition). Thank you very much! > > Brett > >=20 > > ----- Original Message -----=20 > > From: "Gareth White" <gw...@ra...> > > To: <res...@ga...> > > Cc: <gam...@li...> > > Sent: Thursday, February 27, 2003 2:49 PM > > Subject: Re: [GD-Consoles] PS2 floating point > >=20 > >=20 > >> There are indeed subtle differences between the PS2 and the IEEE = implementation. > >>=20 > >> Try the 'EE Core User's Manual' (2nd Edition), Page 77, Chapter 4 > >> 'Floating-Point Unit (FPU)', section 4.8 'IEEE 754 Compatability' > >>=20 > >> Cheers. > >>=20 > >> --- > >> Gareth White - Engine Programmer - Ratbag Pty Ltd > >> Level 8, 63 Pirie Street, Adelaide, SA, Australia, 5000 > >> Ph: +61 8 8223 5830, Fax: +61 8 8223 5746, Mob: 0403 942668 > >> http://www.ratbaggames.com/ > >>=20 > >> ----- Original Message ----- > >> From: "Research (GameBrains)" <res...@ga...> > >> To: <Gam...@li...> > >> Sent: Thursday, February 27, 2003 4:46 PM > >> Subject: [GD-Consoles] PS2 floating point > >>=20 > >>=20 > >> Hello, > >> Our physics engine is experiencing some odd behavior on the PS2. = We traced it > >> to our resting contact force calculation where sometimes it seems = the result is > >> not quite right, but it works fine on other platforms. I don't = know if it's an > >> urban legend or what, but I have heard that the PS2 has some quirks = with regard > >> to floating point numbers and so I thought I would just ask and see = if this is > >> something I need to look at or not. If so, what are the = differences between the > >> PS2 IEEE implementation and is there a doc describing them? > >> Thanks, > >> Brett >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Gamedevlists-consoles mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D553 |
|
From: J. G. <jg-...@jg...> - 2003-02-27 14:31:54
|
Hi Brett, Out of interest what was the problem with your implementation? I found that -fshort-double stopped some of the problems I was having with one issue when I tested some float stuff a while ago. However, if the code is the problem then this would not solve that. JG Research (GameBrains) wrote: > Gareth, > Found it! (moved to chapter 8 in 6th edition). Thank you very much! > Brett > > ----- Original Message ----- > From: "Gareth White" <gw...@ra...> > To: <res...@ga...> > Cc: <gam...@li...> > Sent: Thursday, February 27, 2003 2:49 PM > Subject: Re: [GD-Consoles] PS2 floating point > > >> There are indeed subtle differences between the PS2 and the IEEE implementation. >> >> Try the 'EE Core User's Manual' (2nd Edition), Page 77, Chapter 4 >> 'Floating-Point Unit (FPU)', section 4.8 'IEEE 754 Compatability' >> >> Cheers. >> >> --- >> Gareth White - Engine Programmer - Ratbag Pty Ltd >> Level 8, 63 Pirie Street, Adelaide, SA, Australia, 5000 >> Ph: +61 8 8223 5830, Fax: +61 8 8223 5746, Mob: 0403 942668 >> http://www.ratbaggames.com/ >> >> ----- Original Message ----- >> From: "Research (GameBrains)" <res...@ga...> >> To: <Gam...@li...> >> Sent: Thursday, February 27, 2003 4:46 PM >> Subject: [GD-Consoles] PS2 floating point >> >> >> Hello, >> Our physics engine is experiencing some odd behavior on the PS2. We traced it >> to our resting contact force calculation where sometimes it seems the result is >> not quite right, but it works fine on other platforms. I don't know if it's an >> urban legend or what, but I have heard that the PS2 has some quirks with regard >> to floating point numbers and so I thought I would just ask and see if this is >> something I need to look at or not. If so, what are the differences between the >> PS2 IEEE implementation and is there a doc describing them? >> Thanks, >> Brett |
|
From: Research \(GameBrains\) <res...@ga...> - 2003-02-27 07:41:39
|
Gareth, Found it! (moved to chapter 8 in 6th edition). Thank you very much! Brett ----- Original Message -----=20 From: "Gareth White" <gw...@ra...> To: <res...@ga...> Cc: <gam...@li...> Sent: Thursday, February 27, 2003 2:49 PM Subject: Re: [GD-Consoles] PS2 floating point > There are indeed subtle differences between the PS2 and the IEEE = implementation. >=20 > Try the 'EE Core User's Manual' (2nd Edition), Page 77, Chapter 4 > 'Floating-Point Unit (FPU)', section 4.8 'IEEE 754 Compatability' >=20 > Cheers. >=20 > --- > Gareth White - Engine Programmer - Ratbag Pty Ltd > Level 8, 63 Pirie Street, Adelaide, SA, Australia, 5000 > Ph: +61 8 8223 5830, Fax: +61 8 8223 5746, Mob: 0403 942668 > http://www.ratbaggames.com/ >=20 > ----- Original Message ----- > From: "Research (GameBrains)" <res...@ga...> > To: <Gam...@li...> > Sent: Thursday, February 27, 2003 4:46 PM > Subject: [GD-Consoles] PS2 floating point >=20 >=20 > Hello, > Our physics engine is experiencing some odd behavior on the PS2. We = traced it > to our resting contact force calculation where sometimes it seems the = result is > not quite right, but it works fine on other platforms. I don't know = if it's an > urban legend or what, but I have heard that the PS2 has some quirks = with regard > to floating point numbers and so I thought I would just ask and see if = this is > something I need to look at or not. If so, what are the differences = between the > PS2 IEEE implementation and is there a doc describing them? > Thanks, > Brett >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: Scholarships for Techies! > Can't afford IT training? All 2003 ictp students receive scholarships. > Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. > www.ictp.com/training/sourceforge.asp > _______________________________________________ > Gamedevlists-consoles mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_idU3 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: Scholarships for Techies! > Can't afford IT training? All 2003 ictp students receive scholarships. > Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. > www.ictp.com/training/sourceforge.asp > _______________________________________________ > Gamedevlists-consoles mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D553 |
|
From: Gareth W. <gw...@ra...> - 2003-02-27 06:38:12
|
There are indeed subtle differences between the PS2 and the IEEE implementation. Try the 'EE Core User's Manual' (2nd Edition), Page 77, Chapter 4 'Floating-Point Unit (FPU)', section 4.8 'IEEE 754 Compatability' Cheers. --- Gareth White - Engine Programmer - Ratbag Pty Ltd Level 8, 63 Pirie Street, Adelaide, SA, Australia, 5000 Ph: +61 8 8223 5830, Fax: +61 8 8223 5746, Mob: 0403 942668 http://www.ratbaggames.com/ ----- Original Message ----- From: "Research (GameBrains)" <res...@ga...> To: <Gam...@li...> Sent: Thursday, February 27, 2003 4:46 PM Subject: [GD-Consoles] PS2 floating point Hello, Our physics engine is experiencing some odd behavior on the PS2. We traced it to our resting contact force calculation where sometimes it seems the result is not quite right, but it works fine on other platforms. I don't know if it's an urban legend or what, but I have heard that the PS2 has some quirks with regard to floating point numbers and so I thought I would just ask and see if this is something I need to look at or not. If so, what are the differences between the PS2 IEEE implementation and is there a doc describing them? Thanks, Brett ------------------------------------------------------- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp _______________________________________________ Gamedevlists-consoles mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles Archives: http://sourceforge.net/mailarchive/forum.php?forum_idU3 |
|
From: Research \(GameBrains\) <res...@ga...> - 2003-02-27 06:16:14
|
Hello, Our physics engine is experiencing some odd behavior on the PS2. We = traced it to our resting contact force calculation where sometimes it = seems the result is not quite right, but it works fine on other = platforms. I don't know if it's an urban legend or what, but I have = heard that the PS2 has some quirks with regard to floating point numbers = and so I thought I would just ask and see if this is something I need to = look at or not. If so, what are the differences between the PS2 IEEE = implementation and is there a doc describing them? Thanks, Brett |
|
From: Brian H. <bri...@py...> - 2003-02-26 20:19:04
|
>Debugging C++ code in Visual Studio is, however, so much nicer= than >doing it with SN Systems debugger (which is what we're using)= that >it's worth making the code run on the PC in addition to on the= PS2. We ran into the same issue with PocketPC. It is much, much= easier to develop on the desktop and then abstract so that there is minimal= system specific debugging for the target machine. Brian |
|
From: <chr...@pl...> - 2003-02-26 20:10:49
|
>Out of interest do you compile your video games for MS-Windows with the >same graphics libs as on the console? (Using two sets of game >libs/renderware or the like?) We don't have a "graphics lib" as such. I.e. there is no graphics API that the game code works against. The PC rendering -- which is for debugging, not for speed -- just hooks into the midst of the code building a DMA of graphics commands for the PS2 and takes the DMA list, parses it, and uses OpenGL to draw polys. Not the way to go if you were serious about releasing a PC SKU, but we're not (obviously). Debugging C++ code in Visual Studio is, however, so much nicer than doing it with SN Systems debugger (which is what we're using) that it's worth making the code run on the PC in addition to on the PS2. Christer Ericson Sony Computer Entertainment, Santa Monica |
|
From: <chr...@pl...> - 2003-02-26 18:28:14
|
Mick West wrote:
>Since console development is usually cross-platform development (unless
>you work somewhere like Sony), then anything related to cross platform
>development will be of interest to most console programmers.
Well, perhaps I misunderstood, not previously familiar with "Wine",
but I assume it is this product ("Wine - a free Windows implementation
for Linux"):
http://www.winehq.com/
It says:
"Wine is an implementation of the Windows Win32 and Win16 APIs on top of
X and Unix. Think of Wine as a Windows compatibility layer. Wine provides
both a development toolkit (Winelib) for porting Windows sources to Unix
and a program loader, allowing many unmodified Windows
3.x/95/98/ME/NT/W2K/XP
binaries to run under Intel Unixes. Wine works on most popular Intel
Unixes,
including Linux"
So, I'm still confused and I still think my question is valid. What
*really* is the value of this in terms of *consoles*? Did you actually
bother reading the paper? I couldn't find anything relating to consoles
other than the mentioning of "PS2Linux" in one place. What relevant
text did you see?
Perhaps the original author could clarify?
>Of coure, you could argue about this. But nobody cares.
If you don't care, don't bother commenting.
Christer Ericson
Sony Computer Entertainment, Santa Monica
|
|
From: Christopher P. <cph...@re...> - 2003-02-25 10:28:04
|
We certainly got some decent performance gains on PS1 by breaking up our vehicle code into 'wheel <-> ground' interactions and 'car body <-> ground' interactions. Two separate loops over all cars, with the MapHeight() function positioned between them in the handling code. Managed to kill 90% of the i-cache misses. This helped us a lot more than copying a few bits of the car structure into scratchpad did. Before we moved the ground height code into the vehicle handling source, we had to regularly examine the .map file and fiddle a dummy routine padded with nops to sort out the cache alignment, and later found the handling code was stretching out to near 4k anyway as more features went in. Much saner just to put relevant bits of code in the same file. That was in C - C++ probably makes managing this stuff harder, although inlining can help. Oh, and the PS2 has a marginally less brain-dead i-cache, which also helps ;-) Christopher Phillips -----Original Message----- From: Mick West [mailto:mi...@ne...] Sent: 25 February 2003 01:35 To: gam...@li... Subject: RE: [GD-Consoles] what to do with little cash I've got a related question: (Assuming a PS2 style console) Given that you have game objects that are composed of various components (car = physics + collision + AI + script + sound, eg..). Is it better to process this "per-object" (where you iterate over the objects, and updated all its components), or "per-component" (where for each type of component, you iterate over each instance of the component type, and update it) Per-component might give you better usage of the I-Cache, but per-object might give you better D-Cache usage. Again, I suspect that "it depends", but has anyone thought about this? Anyone tried restructuring code one way or the other? Mick. -Virus scanned and cleared ok |
|
From: Jason G D. <jas...@py...> - 2003-02-25 08:42:29
|
> I've got a related question: > > (Assuming a PS2 style console) I'm going to assume an actual PS2... > Given that you have game objects that are composed of various components > (car = physics + collision + AI + script + sound, eg..). Is it better > to process this "per-object" (where you iterate over the objects, and > updated all its components), or "per-component" (where for each type of > component, you iterate over each instance of the component type, and > update it) > > Per-component might give you better usage of the I-Cache, but per-object > might give you better D-Cache usage. True. In fact, if you try to rely on either (or both) caches without explicitly optimising anything, you'll probably get pretty poor performance. I'd normally expect the D-Cache misses to be roughly double those of the I-Cache however. Optimising for I-Cache usage is not easy, at least beyond the level of simply reducing the amount of code executed and trying to keep it sequential. In fact, just to go back to the original question, using C++ features like virtual functions or in fact any coding practice which encourages the developer to write routines which are liable to be scattered randomly around in memory will tend to thrash the I-Cache even more. We can often spot the difference between C and C++ purely by the amount of I-Cache thrashing on a performance analyser graph. It's not a problem of the language itself so much as the way people typically use it, and the compiler/linker 's inability to optimise anything for cache usage. Optimising for D-Cache usage is an easier option. Even just inserting some prefetch operations in the right place can help out. Beyond that, you can start pulling things into scratchpad ram via DMA, or use uncached memory pointers to load/store things that are better off not polluting the cache. Basically, there are a lot of options for improving data access. So what I'd suggest, is to spend time optimising data usage first. Once you know you have really efficient routines in that aspect you can start trying to rearrange the code to be friendly to the I-Cache as well. You *might* get faster code by splitting into several, tighter passes, but only if you have particularly good data usage in the first place. Of course if you're talking about passes over objects that use competely different data sets (the rendering and collision and AI may not share anything other than a transform for example) then I'd certainly recommend doing different passes. Don't run one bit of code, and then run different code over different data and before trying to reuse something you just discarded... thats just asking for trouble. I'd certainly try to limit what I try doing with the language in a confined, performance critical environment such as a console. I don't just mean for your graphics engine either. Typically the performance of the engine is one of the better parts of the code and the real problems lie in the other, less well optimised sections. Profile often, use the performance counters, keep looking at the code being output from the compiler and experiment with different code structures until you find one that gives you the most comfortable trade off between performance and ease-of-coding. Oh, and offload stuff into VU0 microcode - apart from running in parallel, it reduces I-Cache hits (as opposed to macromode coding, which makes it worse). Getting data in and out can be fiddly, but does force you to think pretty hard about organising data and reducing the amount of it you process, so that can be a good thing anyway... Cheers, Jase -- Jason G Doig Principal Engineer Technology Group (R&D) Sony Computer Entertainment Europe |
|
From: Mick W. <mi...@ne...> - 2003-02-25 01:35:10
|
If you have little cash, you must invest wisely.
The devil is in the details however. I'm sure many successful console
developers have complex class heirachies, and lots of virtual functions.
The virtual function overhead is reall not that bad, unless you are
talking about really low level rendering components (you would not want,
for example, to have a virtual "render" function for every polygon. The
line has to be drawn, but it's open to experimentation.
I've got a related question:
(Assuming a PS2 style console)
Given that you have game objects that are composed of various components
(car = physics + collision + AI + script + sound, eg..). Is it better
to process this "per-object" (where you iterate over the objects, and
updated all its components), or "per-component" (where for each type of
component, you iterate over each instance of the component type, and
update it)
Per-component might give you better usage of the I-Cache, but per-object
might give you better D-Cache usage.
Again, I suspect that "it depends", but has anyone thought about this?
Anyone tried restructuring code one way or the other?
Mick.
-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Raymond L. Maple
Sent: Monday, February 24, 2003 2:14 PM
To: gam...@li...
Subject: [GD-Consoles] what to do with little cash
Hello! I have a question about programming a console that has a small
cache. Now I'm new to this console so I don't know all the details
about it except I've read from other people on this group about how the
cache is very small and that you can stall the the system if you don't
watch out. I was wondering if you could give me any tips and pointers
about what to watch out for in a engine framework or composition. For
example, I heard you want to avoid virtual functions because the vtable
can cause a cache miss. The problem is I do mostly c++ with a good deal
of virtual functions. Does this mean I can't use an object heirarcy
with virtual or pure virtual functions? My main concern is that my
engine layout is a pretty strict c++ implementation and I'm worried the
performance will suffer. I've looked through the documention on the
website provided for the console and I didn't see anything specific to
my question but if you know of anything let me know. I appreciate your
time and knowledge.
Thanks,
Raymond L. Maple
WayForward Technologies
|
|
From: J. G. <jg-...@jg...> - 2003-02-25 01:17:46
|
Hi Phil, I find that gcc's output fixes many bugs MS VC++ does not see, and a few the other way too. Out of interest do you compile your video games for MS-Windows with the same graphics libs as on the console? (Using two sets of game libs/renderware or the like?) Cheers! JG phi...@pl... wrote: > Oddly enough, we cross-compile to the PC. Not the most efficient renderer, > but the debugging's easier. The more compilers you run your code through, > the more stuff gets caught automatically. > > Cheers, > Phil > > PS Since the toolset invariably includes some of the engine code, and > almost certainly doesn't actually run on the console in question, the jab > at Sony, would be more accurately directed at our friends in Redmond > (either of them, I don't care...;) |
|
From: <phi...@pl...> - 2003-02-25 00:39:04
|
Oddly enough, we cross-compile to the PC. Not the most efficient renderer,
but the debugging's easier. The more compilers you run your code through,
the more stuff gets caught automatically.
Cheers,
Phil
PS Since the toolset invariably includes some of the engine code, and
almost certainly doesn't actually run on the console in question, the jab
at Sony, would be more accurately directed at our friends in Redmond
(either of them, I don't care...;)
"Mick West" <mi...@ne...>
Sent by: To: <gam...@li...>
gam...@li...urc cc:
eforge.net Fax to:
Subject: RE: [GD-Consoles] Compiling MS-Windows Builds Under Wine
02/24/2003 04:07 PM
Please respond to gamedevlists-consoles
Since console development is usually cross-platform development (unless
you work somewhere like Sony), then anything related to cross platform
development will be of interest to most console programmers.
Of coure, you could argue about this. But nobody cares.
Mick.
> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...] On
> Behalf Of chr...@pl...
> Sent: Monday, February 24, 2003 3:46 PM
> To: gam...@li...
> Subject: RE: [GD-Consoles] Compiling MS-Windows Builds Under Wine
>
>
>
> Troy Gilbert wrote:
> >As was mentioned at the top of post, the document was written in
> furtherance
> >of a PS2Linux project. Perhaps a second-degree relation to a console
> >(or third-degree...).
>
> No, really. My question stands. How _exactly_ does this
> relate to, say, the development of a PS2, GameCube or even a GBA game?
>
>
> Christer Ericson
> Sony Computer Entertainment, Santa Monica
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gamedevlists-consoles mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles
> Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=553
>
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Gamedevlists-consoles mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=553
|
|
From: J. G. <jg-...@jg...> - 2003-02-25 00:29:04
|
Hi Christer Ericson, Appologies, I sent this went to the wrong address. However, porting to PS2Linux was the reason the MS-Windows builds moved to the same dev enviroment. JG chr...@pl... wrote: > Troy Gilbert wrote: >>As was mentioned at the top of post, the document was written in > furtherance >>of a PS2Linux project. Perhaps a second-degree relation to a console (or >>third-degree...). > > No, really. My question stands. How _exactly_ does this relate to, say, > the development of a PS2, GameCube or even a GBA game? > > > Christer Ericson > Sony Computer Entertainment, Santa Monica |
|
From: Mick W. <mi...@ne...> - 2003-02-25 00:07:58
|
Since console development is usually cross-platform development (unless you work somewhere like Sony), then anything related to cross platform development will be of interest to most console programmers. Of coure, you could argue about this. But nobody cares. Mick. > -----Original Message----- > From: gam...@li... > [mailto:gam...@li...] On > Behalf Of chr...@pl... > Sent: Monday, February 24, 2003 3:46 PM > To: gam...@li... > Subject: RE: [GD-Consoles] Compiling MS-Windows Builds Under Wine > > > > Troy Gilbert wrote: > >As was mentioned at the top of post, the document was written in > furtherance > >of a PS2Linux project. Perhaps a second-degree relation to a console > >(or third-degree...). > > No, really. My question stands. How _exactly_ does this > relate to, say, the development of a PS2, GameCube or even a GBA game? > > > Christer Ericson > Sony Computer Entertainment, Santa Monica > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Gamedevlists-consoles mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles > Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=553 > |
|
From: <chr...@pl...> - 2003-02-24 23:50:26
|
Troy Gilbert wrote: >As was mentioned at the top of post, the document was written in furtherance >of a PS2Linux project. Perhaps a second-degree relation to a console (or >third-degree...). No, really. My question stands. How _exactly_ does this relate to, say, the development of a PS2, GameCube or even a GBA game? Christer Ericson Sony Computer Entertainment, Santa Monica |
4 messages has been excluded from this view by a project administrator.
