gamedevlists-general — List for discussing general game development issues

Re: [GD-General] Compile times

[<cas...@ya...>]

Jesse Jones wrote:
> I have some thoughts on how this can be done, but I'd like to hear
> some more details on how you've implemented this. :-)

Well, that was mentioned some time ago in the Algorithm mailing list by Tom
Forsyth, I think... However, I saw that for the first time in the fmod sound
library to handle channel references.

Here is a snip from his mail:

"Personally I prefer unique IDs. The bottom n bits are an index into an
array
(either of pointers to the object, or if the object is small enough, just an
array of actual objects). The top 32-n bits are the "unique" part. Every
time you allocate an item in the array, the top bits are incremented.
Unless you really do get through a huge number of objects during your game,
32
bits for IDs is more thna enough. It means you can easily kill objects any
time you like, and then when they are requested, you can return either NULL,
or a placeholder, or whatever (as appropriate, e.g. if a texture is
requested
that isn't loaded any more, we return a 16x16 copy, which we always keep
resident for all textures)."

And this is from the FMOD documentation:

"The channel handle :
The return value is reference counted. This stops the user from updating a
stolen channel.
Basically it means the only sound you can change the attributes (ie
volume/pan/frequency/3d position) for are the one you specifically called
playsound for. If another sound steals that channel, and you keep trying to
change its attributes (ie volume/pan/frequency/3d position), it will do
nothing.
This is great if you have sounds being updated from tasks and you just
forget about it.
You can keep updating the sound attributes and if another task steals that
channel, your original task wont change the attributes of the new sound!!!
The lower 12 bits contain the channel number. (yes this means a 4096 channel
limit for FMOD :)
The upper 19 bits contain the reference count.
The top 1 bit is the sign bit.
ie. S RRRRRRRRRRRRRRRRRRR CCCCCCCCCCCC"

Sorry the copy&past thing, but English is not my mother language and I think
this way is clearer and faster. :-)

I don't think that handles are the solution to all the problems and that
smart pointers are bad. However, I think that there are many ways of using
smart pointers wrong, while the handle method is simple and errors are easy
to catch.


Ignacio Castaño
cas...@ya...



_______________________________________________________________
Copa del Mundo de la FIFA 2002
El único lugar de Internet con vídeos de los 64 partidos. 
¡Apúntante ya! en http://fifaworldcup.yahoo.com/fc/es/

RE: [GD-General] Redundant Include Guards

[Mick W. <mi...@ne...>]

GCC does not need redundant include guards of the form you show below.
Header files with internal guards will only be opened once.

The only caveat is that you have to use the exact same path, including
case, it you do something like:

#include "header.h"

then later in the same compilation unit.

#include "sys\header.h"

where they both refer to the same file, then it will get opened twice.
This is not typically a big problem,  just possibly confusing. 

Mick.

> -----Original Message-----
> From: gam...@li... 
> [mailto:gam...@li...] On 
> Behalf Of Parveen Kaler
> Sent: Sunday, December 15, 2002 6:27 PM
> To: gam...@li...
> Subject: [GD-General] Redundant Include Guards
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Sticking with the theme of compile times.
> 
> I'm reading Large-Scale C++ Software Design at the moment.  
> The author 
> recommends redundant include guards in .h files:
> 
> // foo.h
> #ifndef _INCLUDE_FOO_H_
> #define _INCLUDE_FOO_H_
> 
> 
> #ifndef _INCLUDE_BAR_H_
> #include "bar.h"
> #endif
> 
> #ifndef _INCLUDE_VECTOR_
> #include <vector>
> #define _INCLUDE_VECTOR_
> #endif
> 
> ////
> ....
> ////
> 
> #endif
> 
> So I tried this for a project of mine that consists of about 10KLOC. 
> Compiling with gcc3.2 I saw no difference in compile times.
> 
> Are compilers like gcc and msvc smart enough to figure stuff 
> like this 
> out?  Or is my project just not large enough?  The book was 
> written way 
> back in 1996, so I'm figuring some of the advice may be a 
> little out of 
> date.
> 
> Parveen
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQE9/Tnw6jdpm1dGc/cRAiCsAKCb2DuzooUpjSfzd3iFBDO9RexURgCeKHR6
> uOTV9eicFER6so6dh5PJyJY=
> =nVAC
> -----END PGP SIGNATURE-----
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility 
> Learn to use your power at OSDN's High Performance Computing 
> Channel http://hpc.devchannel.org/ 
> _______________________________________________
> Gamedevlists-general mailing list 
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=557
> 

Re: [GD-General] Compile times

[Kent Q. <ken...@co...>]

At 08:19 PM 12/15/2002 -0600, you wrote:
>Memory management bugs are something you encounter when learning how to
>program, but at some point they cease to be a significant problem when
>there is proper discipline in place.


You've said something similar to the "proper discipline" comment several 
times now, and I think you've got a blind spot going on here. If you're 
coding by yourself, personal discipline is all you need. But if you're 
coding on a team, you have to have discipline that applies to everyone on 
the team. And not everyone is a coding machine. Not everyone works on all 
the code all the time.

Even if every individual has perfect discipline in their own code (hah!), 
you'll find errors in the integration -- in the interfaces between modules. 
The old "He allocated it but *I* need to free it" is one example of the 
problem.

I've worked on big teams, small teams, and by myself. And some of the stuff 
you've dissed lately -- wrapping allocations in smart pointers, typesafe 
containers, and so forth -- are useful in almost direct proportion to the 
number of people working on the code. Though I still think that I benefit 
greatly -- even as an individual code -- from such things. It lets me think 
at a higher level.

         Kent




Kent Quirk, CTO, CogniToy
ken...@co...
http://www.cognitoy.com 

Re: Smart pointers was RE: [GD-General] Compile times

[Thatcher U. <tu...@tu...>]

On Dec 16, 2002 at 04:05 -0800, Jesse Jones wrote:
> At 8:16 PM -0600 12/15/02, brian hook wrote:
> >Assuming that we're defining "smart pointer" as ref-counted,
> >templatized pointer access, then here are the typical bugaboos:

[snip]

> Well, what are the options?

Brian and Ignacio mentioned handles.  It seems to me that handles are
equivalent to smart pointers, with a few differences in details.  The
similarities:

* If your handle manager keeps a ref-count (or something similar) to
  avoid deleting an object that has an active handle, then handles
  essentially behave like ref-counted smart pointers.

* If your handle manager is allowed to delete objects when it feels
  like it, then handles are essentially the same as weak pointers,
  with a strong pointer in the handle manager.

And the differences:

* Weak pointers are bigger than handles (the implementation we use has
  an object pointer plus two list link pointers).

* Handles are hard to debug!

* Handles involve a little extra plumbing in the client, to extract a
  real pointer.

-- 
Thatcher Ulrich
http://tulrich.com

Re: [GD-General] Compile times

[Jesse J. <jes...@mi...>]

At 8:19 PM -0600 12/15/02, brian hook wrote:
>  > but now I feel much more comfortable with my 'simple' handles.
>
>I think this is also a big part of my gripe with smart pointers -- much
>like STL, I don't see them solving real world problems.

For the most part that might be true if you're not using exceptions. 
But if you are then it's IMO nearly mandatory to encapsulate the act 
of newing/deleting into a class (like std::auto_ptr) and similarly 
adding/removing references.

Even if you aren't using exceptions manually managing ref counts can 
get pretty hairy with large code bases. (I saw this with InDesign 
which is a huge desktop publishing system which used ref counting 
*very* heavily, but exceptions very little, and didn't add a smart 
pointer class until late in development).

   -- Jesse

Re: Smart pointers was RE: [GD-General] Compile times

[Jesse J. <jes...@mi...>]

At 8:16 PM -0600 12/15/02, brian hook wrote:
>  > Hmm, I've seen smart pointers used on several projects and they have
>>  never caused any problems. What sort of "ugly things" are you
>>  referring to?
>
>Assuming that we're defining "smart pointer" as ref-counted,
>templatized pointer access, then here are the typical bugaboos:

Well reference counted smart pointers are probably the most often 
used, but there are also things like std::auto_ptr (useful with 
exceptions) and somewhat more esoteric things (for example I use a 
smart pointer class for preference data that I am very happy with).

>- non-deterministic destruction (a problem with general GC as well)

How so? With a real GC objects aren't deleted until the collector 
gets around to freeing them, but with all the ref-counted smart 
pointer classes I've seen they are deleted when the last reference is 
released.

>- extremely slack model of ownership (a problem with general GC as well)

That's a feature. :-)

>- cascading destruction if you deref a root node

Why is this a problem?

>- array support can be iffy depending on the implementation

Nah, this is easy to handle as long as you properly define the smart 
pointer's copy ctor and assignment operators (and your array classes 
are coded correctly).

>- cycles

Yeah, that can be a pain but it's not really an issue with smart 
pointers per se.

>- bugs that arise if your implementation doesn't properly handle stack,
>static/global variables, or "special" memory that requires its own de-
>allocation (pointer to surfaces, pointer to AGP memory, etc.)

These are all non-issues in my experience (even the last one: you 
don't delete a surface for example, you delete a class that wraps 
surfaces).

>All that said, there are some pretty solid implementations (Boost?) out
>there that I believe address at least the key issues.

boost:shared_ptr is a good class to look at.

>My gripes are generally more of the subjective stuff -- I think it
>obfuscates code, lends to programmer laziness because there's a poor
>concept of memory ownership and, deep down inside (okay, maybe right
>there at the surface), I just feel that retrofitting automatic memory
>management on a language that was clearly designed for manual memory
>management is a Bad Idea.

Well, what are the options? In my experience automating reference 
counting with smart pointers is a hell of a lot better than doing it 
manually. Doing all the memory management manually with naked calls 
to new and delete is feasible with discipline and some programming 
conventions, but there are usually a few instances where this becomes 
difficult.

   -- Jesse

Re: [GD-General] Compile times

[Jesse J. <jes...@mi...>]

At 3:12 AM +0100 12/16/02, Ignacio Casta=F1o wrote:
>Jesse Jones wrote:
>>  Hmm, I've seen smart pointers used on several projects and they have
>>  never caused any problems. What sort of "ugly things" are you
>>  referring to?
>
>I've seen ugly things when used wrong. For example, when using ciclyc
>references. I allowed weak references to avoid cycles, but ended using them
>in places where I shoudn't and the end I had the feeling of not having too
>much control over the life of the objects. They definitely increase
>complexity, at least when you have never used them :-)
>
>After that, I switched to a handle based resource manager, much more robust
>than the previous code. You have total control over the life of the objects
>and if you mix the handle with a reference count, you detect invalid
>references inmediatly.

I have some thoughts on how this can be done, but I'd like to hear 
some more details on how you've implemented this. :-)

   -- Jesse

RE: [GD-General] Redundant Include Guards

[Arjen B. <arj...@ga...>]

Not sure about that. It does have "#pragma once" though, which "specifies
that the file, in which the pragma resides, will be included (opened) only
once by the compiler in a build."

Arjen Beij | AI Programmer

Lost Boys Games | Prins Hendrikkade 139 | 1011AS Amsterdam The Netherlands
Tel: +31 (0)20 4272277 | Fax: +31 (0)20 4274040 |
arj...@ga...
www.games.lostboys.com

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Dirk Ringe
> Sent: Monday, December 16, 2002 09:27
> To: gam...@li...
> Subject: RE: [GD-General] Redundant Include Guards
>
>
> At least GCC is smart enough to prevent opening header files if they are
> guarded by include guard defines and when they are already parsed. Whether
> this applies to MSVC i do not know.
>
> Dirk

Re: [GD-General] Redundant Include Guards

[Javier A. <ja...@py...>]

gcc detects include guards automatically and will not reopen a guarded
header, at least it used to... msvc has the #pragma once thing so I guess it
doesn't autodetect guarded headers.

That said, the first thing you want to do is structure your code and headers
so that the number of header files included by other headers files (main
source of re-includes) is minimal. Once you're there, redundant include
guards buy you less and less.

Parveen Kaler <pk...@sf...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Sticking with the theme of compile times.
>
> I'm reading Large-Scale C++ Software Design at the moment.  The author
> recommends redundant include guards in .h files:
>
> So I tried this for a project of mine that consists of about 10KLOC.
> Compiling with gcc3.2 I saw no difference in compile times.
>
> Are compilers like gcc and msvc smart enough to figure stuff like this
> out?  Or is my project just not large enough?  The book was written
> way back in 1996, so I'm figuring some of the advice may be a little
> out of date.

  Javier Arevalo
  Pyro Studios

RE: [GD-General] Redundant Include Guards

[Dirk R. <ri...@ph...>]

At least GCC is smart enough to prevent opening header files if they are
guarded by include guard defines and when they are already parsed. Whether
this applies to MSVC i do not know.

Dirk

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Parveen Kaler
Sent: Monday, December 16, 2002 3:27 AM
To: gam...@li...
Subject: [GD-General] Redundant Include Guards


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sticking with the theme of compile times.

I'm reading Large-Scale C++ Software Design at the moment.  The author
recommends redundant include guards in .h files:

// foo.h
#ifndef _INCLUDE_FOO_H_
#define _INCLUDE_FOO_H_


#ifndef _INCLUDE_BAR_H_
#include "bar.h"
#endif

#ifndef _INCLUDE_VECTOR_
#include <vector>
#define _INCLUDE_VECTOR_
#endif

////
....
////

#endif

So I tried this for a project of mine that consists of about 10KLOC.
Compiling with gcc3.2 I saw no difference in compile times.

Are compilers like gcc and msvc smart enough to figure stuff like this
out?  Or is my project just not large enough?  The book was written way
back in 1996, so I'm figuring some of the advice may be a little out of
date.

Parveen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE9/Tnw6jdpm1dGc/cRAiCsAKCb2DuzooUpjSfzd3iFBDO9RexURgCeKHR6
uOTV9eicFER6so6dh5PJyJY=
=nVAC
-----END PGP SIGNATURE-----



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=557

[GD-General] Redundant Include Guards

[Parveen K. <pk...@sf...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sticking with the theme of compile times.

I'm reading Large-Scale C++ Software Design at the moment.  The author 
recommends redundant include guards in .h files:

// foo.h
#ifndef _INCLUDE_FOO_H_
#define _INCLUDE_FOO_H_


#ifndef _INCLUDE_BAR_H_
#include "bar.h"
#endif

#ifndef _INCLUDE_VECTOR_
#include <vector>
#define _INCLUDE_VECTOR_
#endif

////
....
////

#endif

So I tried this for a project of mine that consists of about 10KLOC. 
Compiling with gcc3.2 I saw no difference in compile times.

Are compilers like gcc and msvc smart enough to figure stuff like this 
out?  Or is my project just not large enough?  The book was written way 
back in 1996, so I'm figuring some of the advice may be a little out of 
date.

Parveen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE9/Tnw6jdpm1dGc/cRAiCsAKCb2DuzooUpjSfzd3iFBDO9RexURgCeKHR6
uOTV9eicFER6so6dh5PJyJY=
=nVAC
-----END PGP SIGNATURE-----

Re: [GD-General] Compile times

[brian h. <bri...@py...>]

> but now I feel much more comfortable with my 'simple' handles.

I think this is also a big part of my gripe with smart pointers -- much 
like STL, I don't see them solving real world problems.  They sound 
great in theory, but any well engineered project will have a pretty 
firm grasp on memory allocation, free and ownership policies.

Memory management bugs are something you encounter when learning how to 
program, but at some point they cease to be a significant problem when 
there is proper discipline in place.

-Hook

Smart pointers was RE: [GD-General] Compile times

[brian h. <bri...@py...>]

> Hmm, I've seen smart pointers used on several projects and they have 
> never caused any problems. What sort of "ugly things" are you 
> referring to?

Assuming that we're defining "smart pointer" as ref-counted, 
templatized pointer access, then here are the typical bugaboos:

- non-deterministic destruction (a problem with general GC as well)

- extremely slack model of ownership (a problem with general GC as well)

- cascading destruction if you deref a root node

- array support can be iffy depending on the implementation

- cycles

- bugs that arise if your implementation doesn't properly handle stack, 
static/global variables, or "special" memory that requires its own de-
allocation (pointer to surfaces, pointer to AGP memory, etc.)

All that said, there are some pretty solid implementations (Boost?) out 
there that I believe address at least the key issues.

My gripes are generally more of the subjective stuff -- I think it 
obfuscates code, lends to programmer laziness because there's a poor 
concept of memory ownership and, deep down inside (okay, maybe right 
there at the surface), I just feel that retrofitting automatic memory 
management on a language that was clearly designed for manual memory 
management is a Bad Idea.

-Hook

Re: [GD-General] Compile times

[<cas...@ya...>]

Jesse Jones wrote:
> Hmm, I've seen smart pointers used on several projects and they have
> never caused any problems. What sort of "ugly things" are you
> referring to?

I've seen ugly things when used wrong. For example, when using ciclyc
references. I allowed weak references to avoid cycles, but ended using them
in places where I shoudn't and the end I had the feeling of not having too
much control over the life of the objects. They definitely increase
complexity, at least when you have never used them :-)

After that, I switched to a handle based resource manager, much more robust
than the previous code. You have total control over the life of the objects
and if you mix the handle with a reference count, you detect invalid
references inmediatly.

Of course, if I used smart pointers again, I wouldn't make the same errors,
but now I feel much more comfortable with my 'simple' handles.


Ignacio Castaño
cas...@ya...


___________________________________________________
Yahoo! Sorteos
Consulta si tu número ha sido premiado en
Yahoo! Sorteos http://loteria.yahoo.es

RE: [GD-General] Compile times

[Jesse J. <jes...@mi...>]

At 6:19 PM -0800 12/9/02, Brian Hook wrote:
>That's a fairly accurate assessment of my feelings, coupled with a
>strong feeling that a lot of the complexity is also designed in from the
>outset because of a belief that it's necessary.  The case in point I use
>are smart pointers, which almost always end up costing more than they're
>worth in projects I've seen.  Those are typically designed in from day
>one because they seem like a good idea, but then in practice enough ugly
>things rear their heads that everyone ends up regretting them at the
>end.

Hmm, I've seen smart pointers used on several projects and they have 
never caused any problems. What sort of "ugly things" are you 
referring to?

   -- Jesse

Re: [GD-General] Compile times

[Thatcher U. <tu...@tu...>]

On Dec 09, 2002 at 11:38 -0600, brian hook wrote:
>  
> > Unfortunately the link time didn't seem to drop any, which is the
> 
> Are your codebases built into a single monolithic EXE, or an EXE and
> multiple DLLs?  The latter approach seems to help link times
> appreciably.

It's monolithic (this is for Xbox; dunno if something DLL-like is
possible).

> Speaking of which, I'm curious if anyone has tried using jam (Just
> Another Make)?  make isn't even quite 80s technology, much less
> 2000+ technology.  It's mind bogglingly obtuse, yet somehow manages
> to survive even today.  jam is an attempt to sort out this mess
> somewhat more cleanly, and Apple has migrated to it for
> ProjectBuilder.

I gave Jam the "old college try" on an earlier version of the code at
Oddworld.  I eventually decided it was just as cryptic as make, but
cryptic in a way that's less familiar, less well documented, and less
actively supported (compared to GNU make).  I ran into numerous quirks
with NT shell limitations, and confusion trying to shoehorn Xbox's
build process into Jam's model.  I have no doubt that it can be made
to work smoothly, but I also think it offers no compelling advantage
over GNU make, so for me it's a devil-you-know
vs. devil-you-don't-know situation.

Also, this (extremely practical and informative) paper convinced me
that Jam's vaunted speed advantage over make is due to widespread
misuse of make, rather than a fundamental problem:

http://www.tip.net.au/~millerp/rmch/recu-make-cons-harm.html

-- 
Thatcher Ulrich
http://tulrich.com

Re: [GD-General] Last-second snag with J2ME midlet on T720 phone...

[Parveen K. <pk...@sf...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Colin Fahey wrote:
[snip]
> 
> http://www.colinfahey.com/2002dec14_j2me_cell_phone/j2me_phone_apps.htm
> 
> Even if you know nothing about cell phone development,
> you might be able to get your own application running
> on your phone just by following the steps on the page
> above.
> 

There's a thread going on over at slashdot about this.
http://developers.slashdot.org/article.pl?sid=02/12/14/160201&mode=thread&tid=100
As per usual, signal-to-noise is pretty low.

I have friend that is currently making cell phone games.  I believe he 
is using PHP and mysql.  This is the middle-man he is contracted with to 
take care of distribution, billing, etc.
http://airg.com

I have a few questions though about your article.

j2me is supposedly much slower than brew.  What's your experience with 
this?  Is there a good, easy way to bill customers so you can actually 
make money?

The next version of brew may actually use the gcc arm compiler.  Which 
will save a developer $1500.  But how much does Qualcomm charge for 
signatures/testing?

Parveen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE9+6+y6jdpm1dGc/cRAtE1AKCpE8AFzHBW2VWC5CFr35qcAKTCCACgqSfu
gsJU0rE/e80nFLSPF1H+Mz0=
=saS5
-----END PGP SIGNATURE-----

Re: [GD-General] Last-second snag with J2ME midlet on T720 phone...

[Colin F. <cp...@ea...>]

2002 December 14th
Saturday

I figured out what was wrong: I was missing the manifest
file in the *.JAR file.

Here is my new web page dedicated to describing my
experience of developing, deploying, and downloading
a J2ME application, all for free (apart from "air time"
and "byte transfer"):

http://www.colinfahey.com/2002dec14_j2me_cell_phone/j2me_phone_apps.htm

Even if you know nothing about cell phone development,
you might be able to get your own application running
on your phone just by following the steps on the page
above.

Well, I promise not to ask any more cell phone coding
questions on this list -- since the overwhelming response
to my recent question was clogging all the bandwidth...NOT!

--- Colin
cp...@ea...
www.colinfahey.com

[GD-General] RE: Compile times

[Iain R. <i.n...@re...>]

For what it's worth, my experience shows a marked difference between VC6
and Borland C++ Builder (3 and 4). I'm using BCB, and my complete
rebuild time (on a lowly P2-333, 128MB) is approx 1 minute. It's not a
large project though - approx 70 .c files, all straight C.

However, I did get the opportunity to build it with VC6, and it took
approx 10 minutes! Now, I had my header files optimised for BCB (article
at http://www.bcbdev.com/articles/pch.htm) and it's not hugely pretty,
but it's good for rebuilds, capitalising on cached pch files. After BCB
has created its pch, it literally flies through the source files (maybe
4 a second). I didn't manage to configure VC to rebuild this fast. But
what it shows is that it pays to get to know your compiler, and find out
how to optimise your code for it. And you shouldn't have to put up with
slow compile times. BCB tells you how many lines are being compiled.
Even a small source file can cause the compiler to look at over 200,000
lines of code in headers...

Iain

[GD-General] Last-second snag with J2ME midlet on T720 phone...

[Colin F. <cp...@ea...>]

2002 December 11th
Wednesday

I hate to ask this question here, but I'm like
THIS close to getting my own application to run
on my T720 phone, and this last obstacle is way
more mysterious than I can handle!

I wrote a simple *.java file that uses J2ME.
It compiled to a *.class file, went through
a "preverify" step to become a new *.class
file, and then I put it in to a *.jar file.

I can use the midp application to run the
midlet directly from the *.jar file, and
it executes in a cell phone emulator as
expected.

I have downloaded and executed apps on my
T720 phone, but after downloading my own
app, the phone says "Download Complete",
and then says "2268 bytes transferred",
and then, after a long pause, the
following message appears:

  "Unsupported Content Type"

The *.java code is taken straight from a
extremely simple "Hello, World" demo on
a Sun midlet web site.

Okay, here's what makes all of this weirder:
I did lots of Google searching, and ended
up downloading the Motorola J2ME SDK v3.0,
and I run their phone emulator on that 
same *.jar file -- and it works as expected
on the T720 (my model phone) emulator.

I found many pages (via Google) that contain
the string "Unsupported Content Type", but I
don't see any connection to my problem.

I deployed my app from my WWW site, over
the air (OTA), and the MIME types are 
correct.  I put other people's *.jar and
*.jad files on my WWW site, and I successfully
downloaded these other apps to my phone
and executed them.

Anyone have any idea what might be the 
"missing link"?

We can take it off the list with private
e-mail exchanges if it's too off-topic for
your tastes.  But I've already created a
WWW page that documents in great detail
what I have done so far to get applications
running on my T720 phone -- so it's kind
of frustrating to hit one last snag at 
literally the last possible moment for
something to go wrong!  (By the way,
once someone helps me solve this last
problem, I'll post the entire process
on my WWW site and announce it.)

I don't think my app actually started 
execution because the phone didn't even
store the app in the Games & Apps
repository for future use.

So, was "Unsupported Content Type"
generated by the verification stage
on the phone?  Or is it something even
sillier, like the *.JAR MIME type still
being wrong (despite me specifying:
AddType application/java-archive jar
on the Apache server)?

Or does it have to do with me specifying
the *.jad file directly via the "Open URL"
option on the phone?  Maybe my successful
attempts to get other apps involved going
though HTML or WAP links...

Anyhow, I'm baffled, and I searched the web
and couldn't find any other friendly place
to ask a question like this.  Sorry if this
is way out there for this list.

--- Colin
cp...@ea...

RE: [GD-General] Compile times

[Kent Q. <ken...@co...>]

Every programmer in Codeville liked templates a lot
But the Hook, who lived just west of Codeville did NOT.

The Hook *hated* templates! The whole template thing.
If you want to ask why, then just give him a ring.

It could be that templates are just macros in drag.
It could be that templates made his build process lag.
But I think that the most likely reason of all
Is that his disk drive is two sizes too small.

But whatever the reason, his lag or his macros,
The Hook stood there hating templates down to his toes.
For tomorrow he knew all the coders and geeks
Would use STL to avoid memory leaks

They'd stuff data in vectors!
They'd use maps and lists!
And the thought of a deque...
Well, that just got him pissed.

And then they'd do something
That he liked not a bit
Every last one of them,
The fat and the fit
Would go out on the newsgroups
And start talking about it!



         Ok, the joke's running thin. :-)
         Apologies to both Dr. Seuss and Brian...

                 Kent


At 01:34 PM 12/9/2002 -0800, you wrote:
>The above is exactly what I mean.  STL is the devil's tool, I stand very
>firmly on that.  I completely dislike the way C++ has made templates,
>which are effectively glorified search and replace macros.  It leads to
>code bloat, and changing any of your template code causes massive
>cascades of rebuilds.
>

Kent Quirk, CTO, CogniToy
ken...@co...
http://www.cognitoy.com 

RE: [GD-General] Compile times

[Donavon K. <kei...@ea...>]

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...] On Behalf Of
> Matt Newport
> Sent: Wednesday, December 11, 2002 7:02 AM
> To: gam...@li...
> Subject: RE: [GD-General] Compile times
> 
> Is there a decent profiler for C#? I would be a lot more comfortable
about
> trying it out if I knew that I had a good profiler so I could quickly
spot
> any areas which might be candidates for replacement with C++ code. If
> something with similar functionality to VTune is available for C# (as
far
> as I know VTune itself is not?) then performance concerns would be
easier
> to address.

Apparently VTune 6 profiles .NET (I don't have it myself), so the short
answer to your question would appear to be "Yes."

GotDotNet lists four other commercial profilers and one free profiler.

The .NET CLR has very decent profiling support.  For simple purposes you
can read runtime statistics or look at the performance counters.  It's
also relatively easy to roll your own profiler (see 'Program
Files\Microsoft Visual Studio.NET\FrameworkSDK\Tool Developers
Guide\docs\Profiling.doc').  Matt Pietrek wrote an 'Under the Hood'
article on this
(http://msdn.microsoft.com/msdnmag/issues/01/12/hood/default.aspx).

And I'll just throw this in: "Improve Your Understanding of .NET
Internals by Building a Debugger for Managed Code"
(http://msdn.microsoft.com/msdnmag/issues/02/11/CLRDebugging/default.asp
x)

--Donavon  

Re: [GD-General] Text file parsing

[Tom S. <to...@pi...>]

> If you're starting fresh, I would recommend using XML for structured text
> files. You can use TinyXML to read them (use google to locate it).

    Also take a look at CMarkup ( http://www.firstobject.com/ ).  IMO it's
easier to use than all the other XML parsers i've tried... even ones in Java
and C#.  Tom

----- Original Message -----
From: "Javier Arevalo" <ja...@py...>
To: <gam...@li...>
Sent: Wednesday, December 11, 2002 5:16 AM
Subject: Re: [GD-General] Text file parsing


> We use a structure very similar to ASE for our data definition files.
> Writing the parser for it was about a couple hours.
>
> If you're starting fresh, I would recommend using XML for structured text
> files. You can use TinyXML to read them (use google to locate it).
>
> Marc Fascia <mf...@pu...> wrote:
> > Hello,
> >
> > I'm currently writing a toolkit that will be used as a basis for my
> > next game engine. It will feature one or several editing tools for
> > content creation, as one of the objective is to be data-driven. In
> > the process, I plan to use some intermediate text-based file formats,
> > such as ASE for meshes (easy to export from any modelling packages),
> > text shaders/material files and so on.
> >
> > My question is about the best way of writing file-parsers for these
> > files. I can see currently 2 options
> >
> > 1) use some tools like Lex&Yacc
> > - Pros : easy to use, fast development time, easy to make the grammar
> > evolve
> > - Cons : for now, I was unable to make Lex&Yacc create some nice C++
> > parser class that can be embedded in my tools.
> >
> > 2) write my own from scratch, maybe first writing a DumbParser class
> > that just provides with a bunch of basic string function, acting like
> > a Lexer and derive the different needed parsers from that, embedding
> > the grammar inside
> > - Pros : full control on the design and the implementation, in
> > comparison to the obfuscated code from Ley/Yacc
> > - Cons : more development time, grammar kind of hardcoded so not
> > easily maintainable, I'm not very experienced in writing text parsers
> > :)
> >
> > I wonder how people handle file parsing in their projects.
> > Thanks for your help.
> >
> > -Marc
>
>
>   Javier Arevalo
>   Pyro Studios
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>

Re: [GD-General] Text file parsing

[Ivan-Assen I. <as...@ha...>]

Text file parsingBy the way, if you are feeling TRULY adventurous, 
you might try Spirit (http://spirit.sourceforge.net).

It's a framework? library? metalibrary? for creating
parsers by describing the grammer directly within C++
code via a mindboggling amount of template trickery.

here's their "hello world" example - a parser which
takes a comma-separated list of floats and stuffs them
into a std::vector:

    bool
    parse_numbers(char const* str, vector<double>& v)
    {
        return parse(str,

            //  Begin grammar
            (
                real_p[append(v)] >> *(',' >> real_p[append(v)])
            )
            ,
            //  End grammar

            space_p).full;
    }

Translation: >> means "followed by", and is just whitespace in BNF;
the Kleene star *, means what it usually means, but by obvious
reasons has to be put IN FRONT of the subexpression.

Re: [GD-General] Text file parsing

[Ivan-Assen I. <as...@ha...>]

Text file parsingAnother point in favor of XML is the easiness with which
you can store Unicode characters in it, while keeping it
editable and viewable - just stuff UTF-8 or UTF-16 into an
XML file, set the encoding processing instruction and bingo,
your weird-language characters are there.

(Although, to be honest, we've had problems with encoding
for our XML-based localization tables, as some of the external
localizers (is that a word?) had trouble understanding
instructions like "find where in your software it says Encoding
and set it UTF-8". The only 100% idiot-proof weird-language safe
file format is Excel.)