For each device you have different variables like screen-dimensions, key-codes etc. and that is simply the tip of the iceberg.We can have inlined-functions that act differently for every device.

None of which requires the use of a precompiler. You can define a class (or classes) which define all the device specific items as compile time constants or methods. Any if tests which depend on a compile time constant boolean value will have the never taken branch removed at compile time. Other compile time constants are copied to all classes which use them (not everyone appreciates this behaviour, but it is what you want). Now all you have to do is include the right version of this class at compile time (by suitable selection of sourcepath).If there is a JIT on the target devices and byte code size isn't too critical, you have these choices decided at runtime with negligible performance penalty.

Of course if you really want to pretend that you are writing C, then by all means stick with using a preprocessor.

None of which requires the use of a precompiler. You can define a class (or classes) which define all the device specific items as compile time constants or methods. Any if tests which depend on a compile time constant boolean value will have the never taken branch removed at compile time. Other compile time constants are copied to all classes which use them (not everyone appreciates this behaviour, but it is what you want). Now all you have to do is include the right version of this class at compile time (by suitable selection of sourcepath).If there is a JIT on the target devices and byte code size isn't too critical, you have these choices decided at runtime with negligible performance penalty.

Of course if you really want to pretend that you are writing C, then by all means stick with using a preprocessor.

Well it is not like we want to code in c, but the precompiler lets us do stuff that you just cannot do otherwise.

Developing on mobiles is only about making it as small and as fast as possible. On some phones we are limited to 64k and any classes or stuff we can save is important.

Also like I said with the devices just the screen size and like are not the problem. Yeah that could be handled in a class. The problems are the device specific stuff we need. We currently support 40+ devices and each damn one has some kinda problem or *specialty*.And because of these we need functionality to totally cut off or include portions of code and best that they are not compiled.This can drastically reduce the size of a project.

If I would have to estimate I'd say that 70% of the base code (not game code) is device specific.

In our toolchain we also have command-line bilds. So f.i. if you want to build a S40 debug for a specific customer in a certain language you just enter the parameters and it spits out the finished jad and jar files.

We do have some special classes for stuff like sound and sprites.

But I am very gratefull for your feedback. Sometimes one does need an outside pair of eyes to see problems.If you have any suggestions, please share them.

Using a pre compiler is a rather common thing if you develop for mobile devices. It's just the vast amount of different devices... and each one needs a special build. You can easily end up with 80 different builds or even more. And since you've got just a tiny piece of ram you can't waste space with unused classes.

For that reason I never did anything real for cellular phones... it's just too painfull.

Using a pre compiler is a rather common thing if you develop for mobile devices.

But isn't that just because most of the mobile games studios are ex-C++ programmers?

No-one has yet given an actual reason why you *need* a pre-compiler, as opposed to - say - a half-way decent build system. If your build system can't understand the concept of different build-targets then you need a new build system!

Heck, use Vesta as your SCM and you get a great SCM and a target-based build system thrown in for free .

Ok let's say a Project you are working on has sounds.If you project supports all sound types that gives you about 4 different types (amr, mid, ota, spf).

But each device you compile for has its specialties.Some demand that you do certain stuff before or after. Some you can set the volume or can loop.

Also it could be manditory for your project to not have sound at all, some sounds, setting volume, loading on demand, prefetching, dump after use, some have to be threaded.

Heck some devices even do their vibrations with their sound stuff.

And all that needs to be controlled not on a device level but on build level.

Most important thing of all is that if it is not used, it should not be in the code.Even an empty class costs 200 bytes in the jar.Memory is a BIG problem, expecially the small devices.Often enough we have to go back and trimm stuff out of the apps so they can fit on devices.

And this is simply just for the sound. Sure the MIDP stuff says the devices have to act in this or that way. And most do with the added bug here and there.(f.i. the Nokia 6600 has a memory leak when you append text to forms. But the fix would kill off most low-end devices)

Nearly every part of a project can be different on every device.And we currently support over 9 mobile vendors with 100 devices. Just to give ya an overview.

I wish I could show you an example. But I would welcome any suggestions or proof that it can be done differently.

EDIT: this was posted in response to Onyx, the other reply hadn't appeared yet - I haven't read the post above yet!

Thanks, but...No. I didn't see anything there that I cannot do as described above. Please, which bit of that do you think you can't do without a precompiler? (this, I believe, is the problem - people like Mark and I know how to do these things with standard tools, and so we're looking at the examples and saying "yeah, but I *can* do that. What's the problem?". For my part, I'm probably glossing over something inadvertently, so if someone could point to a particular precise issue, I can at least know exactly where the problem lies, and look at that more carefully..)

Ok let's say a Project you are working on has sounds....And all that needs to be controlled not on a device level but on build level.

EDIT: don't read this in an aggressive tone; it wasn't asked that way.

Do you not understand what I'm talking about when I say "build targets"? Do you not know what a real build-system is? These things were specifically designed to do stuff like select different alternative versions of the same class and inject them into the javac compiler. This stuff is decades old!

EDIT: don't read this in an aggressive tone; it wasn't asked that way.

Do you not understand what I'm talking about when I say "build targets"? Do you not know what a real build-system is? These things were specifically designed to do stuff like select different alternative versions of the same class and inject them into the javac compiler. This stuff is decades old!

Nah, np. Same here. The written word can often sound very tough.But next time I will challenge you to a virtual duel for insulting us.

Well if there IS something that can do all that and is cost effective then gimmegimmegimme.Cus either we are blind and overlooked it or have not looked hard enough.

Another thing that we will need to do then is get it by my bosses. Our tool chain (s cuz version 2) has worked great and is one of the reasons we are as successfull as we are. So the new sys should be at least as good or better.

I really look forward to checking out these tools. Maybe it will make it easyer.

The purpose of a build system is to take your source and build it - where "build" means "compile plus all the other stuff that comes afterwards to create the finished product". Lots of java users use ANT - which I *hate* because the originaly authors made a very stupid mistake and tried to create an imperative scripting language in XML, and the damn thing is a nightmare to use until you become a guru with it - but which is very very very widespread and has scripts for doing lots of stuff.

We use Vesta, which uses a true functional programming language to assemble builds, and which I've posted on in this forum. It's not just a build system - it also does version control (which is part of why I like it, but if you only want a build system that's a pain in the butt; you *cannot* simply use the build part without the version control: so you'd have to replace your current SCM with vesta in order to use it).

Both of those are open source, and there are plenty of others too, but those are the only free ones I've ever used.

Oh, OK, so I've also used the GNU Make-based crap. Don't even bother doing a google for it, it's not worth that much of your precious life - remember you only have one life to live, and a finite number of minutes!

The purpose of a build system is to take your source and build it - where "build" means "compile plus all the other stuff that comes afterwards to create the finished product". Lots of java users use ANT - which I *hate* because the originaly authors made a very stupid mistake and tried to create an imperative scripting language in XML, and the damn thing is a nightmare to use until you become a guru with it - but which is very very very widespread and has scripts for doing lots of stuff.

Yeah we looked at Ant and we were a little put off.

Quote

We use Vesta, which uses a true functional programming language to assemble builds, and which I've posted on in this forum. It's not just a build system - it also does version control (which is part of why I like it, but if you only want a build system that's a pain in the butt; you *cannot* simply use the build part without the version control: so you'd have to replace your current SCM with vesta in order to use it).

Both of those are open source, and there are plenty of others too, but those are the only free ones I've ever used.

Not so good but I will pick up a link and spread it around the office.

Can it also remove/add stuff before building?

Like the link oNyx posted shows we (currently) do stuff similary.

Well let's say we do it that way now and would not really know how to do it differently. And we *really* need the code-injector. Otherwise we would need about 1 class per line of code .... honest.

(If you are interrested I can explain a little how we did the code tree)

Quote

Oh, OK, so I've also used the GNU Make-based crap. Don't even bother doing a google for it, it's not worth that much of your precious life - remember you only have one life to live, and a finite number of minutes!

Hehe... my heart is eating up the available 60billion (or was it million?) beats it has left.

I'm getting curious here. Personally, I have never seen a need for a preprocessor in Java. Can you give a code example where you think a preprocessor is necessary and which can't be replaced by multiple classes selected at build time?

The lack of a preprocessor is one of the reasons I prefer Java over C/C++.

oh and to relate things to game programming. I am beginning to think that annotations + bytecode instrumentation could solve some of the woes people have with moving interleaved data in and out of native buffers.

Or a preprocessor for the lazy typists, that replaces

1

glVertex3f(1, 1, 1);

with

1

gl.glVertex3f(1.0f, 1.0f, 1.0f);

hmm no wait. The gl.gl* expansion would be better as an eclipse-plugin that extends the content assist functions...

Doesn't mean they all *should* be done or are necessary - e.g. the cited Gamasutra article was written by someone who isn't doing their job properly, hired above their level of expertise, since they have written *terrible* java source out of ignorance for how to use java.

Most of them that should be done seem to be attempts to make up for mistakes/omissions by Sun - e.g. AspectJ, Retroweaver etc.

Quote

And with the upcoming support for annotations, I think we will see a lot more uses for pre- and post-processing.

@blahblahblahh:I would not make presumptions about the skills of others without knowing what the landscape they work in is like.

Sure. However, I know that that source is an unnecessary hack, and an abuse of java, concommitant with someone who doesn't "think" in java, and probably doesn't understand it properly. My experiences with similar people in the past - often very good at C++ or some other languages - suggest that this general pattern carries over into other areas of their development. Overall, this tends to exacerbate the knock-on negative effects on the practicality of developing and maintaining any of their source, and hence a negative effect on profitability of their employer.

That said, I was probably overly harsh. Suffice it to say, my natural reaction would be to fire anyone doing something like that, and go pay $100k for a decent highly-experienced development-team leader instead.

Just writing bad source, or fulfilling a game project at 20% greater cost than you ought to have done do not in themselves prevent you from doing the rest of your job (e.g. delivering the project at all is more important than doing so at optimum cost), nor destroy businesses, but they do tend to be bad for the business. So, sure, the company could be the most successful company in the world, but that doesn't mean their staff are all perfect, or even all competent at the roles they're in. Look at id games - developers have worked there who, with hindsight, were clearly mediocre. That situation is repeated all over the industry.

There are, of course, other paradigms of pre compiling other than the C++ type of text expansion macro. The Lisp type of macros are a very different kettle of fish, and are one of the reasons lisp seems to refuse to die. Something similar for java can be seen at http://jse.sourceforge.net/

I've always wondered what the point off them was, as I only see it as a mostly useless way to add unreadable junk to the source code.

Obviously, I'm a bit ignorant here . But if someone could start a new thread and explain what's so great about them, I would be thankful

btw. Ant can substitute new text for particular tokens in the source, without any plugins.. I'm not sure if that would help with the original problem or not.

I personally like Ant. It does a decent job at what it is designed to do. I think people have tried to make it do a bit too much and that leads to the negative perception of using XML as a scripting language, which Ant is not.

besides the aforementioned ant task you can use a user defined builder in eclipse to preprocess files with a preprocessor. run->external tools->external tools->program->newunder the main tab:location: path to your preprocessorworking directory: $(container_loc)arguments: -w -Wall -C -o${container_loc}\preprocessed\${resource_name} ${resource_loc}

refresh: check refresh resources upon completion

now under project->properties->builders->import->(your preprocessor tool)

or if you want to omit the run thingy

project->properties->builders->new

personally i'd prefer the specialized ant task or a complete nature with customized builders within eclipse, which makes it possible to use whatever "toolchain" you're using :-)

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org