RE: what to do with little cash
"Mick West" <[email protected]> Mon, 24 Feb 2003 17:34:36 -0800
| Newsgroups | gmane.games.devel.consoles |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. ------=_NextPart_000_00AD_01C2DC2B.00295B50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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: [email protected] [mailto:[email protected]] On Behalf Of Raymond L. Maple Sent: Monday, February 24, 2003 2:14 PM To: [email protected] 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 ------=_NextPart_000_00AD_01C2DC2B.00295B50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <TITLE>Message</TITLE> <META content=3D"MSHTML 6.00.2800.1141" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><SPAN class=3D390202401-25022003><FONT face=3DArial color=3D#0000ff = size=3D2>If you=20 have little cash, you must invest wisely.</FONT></SPAN></DIV> <DIV><SPAN class=3D390202401-25022003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D390202401-25022003><FONT face=3DArial color=3D#0000ff = size=3D2>The=20 devil is in the details however. I'm sure many successful console=20 developers have complex class heirachies, and lots of virtual = functions. =20 The virtual function overhead is reall not that bad, unless you are = talking=20 about really low level rendering components (you would not want, for = example, to=20 have a virtual "render" function for every polygon. The line = has to=20 be drawn, but it's open to = experimentation.</FONT></SPAN></DIV> <DIV><SPAN class=3D390202401-25022003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D390202401-25022003><FONT face=3DArial color=3D#0000ff = size=3D2>I've=20 got a related question:</FONT></SPAN></DIV> <DIV><SPAN class=3D390202401-25022003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D390202401-25022003><FONT face=3DArial color=3D#0000ff = size=3D2>(Assuming a PS2 style console)</FONT></SPAN></DIV> <DIV><SPAN class=3D390202401-25022003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D390202401-25022003><FONT face=3DArial color=3D#0000ff = size=3D2>Given=20 that you have game objects that are composed of various components (car = =3D=20 physics + collision + AI + script + sound,=20 eg..). Is it better to process this "per-object" = (where you=20 iterate over the objects, and updated all its components), or = "per-component"=20 (where for each type of component, you iterate over each instance of the = component type, and update it)</FONT></SPAN></DIV> <DIV><SPAN class=3D390202401-25022003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D390202401-25022003><FONT face=3DArial color=3D#0000ff = size=3D2>Per-component might give you better usage of the I-Cache,=20 but per-object might give you better D-Cache = usage.</FONT></SPAN></DIV> <DIV><SPAN class=3D390202401-25022003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D390202401-25022003><FONT face=3DArial color=3D#0000ff = size=3D2>Again,=20 I suspect that "it depends", but has anyone thought about this? = Anyone=20 tried restructuring code one way or the other?</FONT></SPAN></DIV> <DIV><SPAN class=3D390202401-25022003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D390202401-25022003><FONT face=3DArial color=3D#0000ff = size=3D2>Mick.</FONT></SPAN></DIV> <DIV><SPAN class=3D390202401-25022003> </SPAN></DIV> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <DIV></DIV> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft><FONT=20 face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20 [email protected]=20 [mailto:[email protected]] <B>On = Behalf Of=20 </B>Raymond L. Maple<BR><B>Sent:</B> Monday, February 24, 2003 2:14=20 PM<BR><B>To:</B>=20 [email protected]<BR><B>Subject:</B> = [GD-Consoles]=20 what to do with little cash<BR><BR></FONT></DIV> <DIV><FONT face=3DArial size=3D2>Hello! I have a question about = programming=20 a console that has a small cache. Now I'm new to this console so = I don't=20 know all the details about it except I've read from other people on = this group=20 about how the cache is very small and that you can stall the the = system if you=20 don't watch out. I was wondering if you could give me any tips = and=20 pointers about what to watch out for in a engine framework or=20 composition. For example, I heard you want to avoid virtual = functions=20 because the vtable can cause a cache miss. The problem is I do = mostly=20 c++ with a good deal of virtual functions. Does this mean I = can't use an=20 object heirarcy with virtual or pure virtual functions? My main = concern=20 is that my engine layout is a pretty strict c++ = implementation=20 and I'm worried the performance will suffer. I've = looked=20 through the documention on the website provided for the console and I = didn't=20 see anything specific to my question but if you know of anything = let me=20 know. I appreciate your time and knowledge.</FONT></DIV> <DIV> </DIV> <DIV><FONT face=3DArial size=3D2> = Thanks,</FONT></DIV> <DIV><FONT face=3DArial size=3D2> Raymond L. = Maple</FONT></DIV> <DIV><FONT face=3DArial size=3D2> WayForward=20 Technologies</FONT></DIV> <DIV><FONT face=3DArial = size=3D2></FONT> </DIV></BLOCKQUOTE></BODY></HTML> ------=_NextPart_000_00AD_01C2DC2B.00295B50-- ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Gamedevlists-consoles mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=553