Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (475)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (530)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  better preprocessor for eclipse  (Read 4501 times)
0 Members and 1 Guest are viewing this topic.
Offline Serethos

Junior Member




Java games rock!


« Posted 2004-10-11 13:57:48 »

currently im using antenna for using preprocessor statements. but it is really annoying that eclipse cant handle them and displays errors for name-collisions etc.
is there any (good) preprocessor out there, which has a full implementation to eclipse ?
Offline gangrel-br

Junior Member




Java and Scala! Thats the game =)


« Reply #1 - Posted 2004-10-11 15:33:26 »

Thats a good question, and not specific to Eclipse. I use Antenna with NetBeans and have exactly the same problem. But I think a better solution would be a plugin for these IDEs to make then understand Antenna preprocess directives, instead of a completly new preprocessor. Is there such a tool Huh

(Did you noticed I like Antenna?  Grin)

Paulo "JCranky" Siqueira
Offline Serethos

Junior Member




Java games rock!


« Reply #2 - Posted 2004-10-13 13:49:43 »

im very disappointed about antenna. theres another problem which gets more and more annoying:

i really need preprocessor statement which can compare to a value, like

<code>
//# if( ${used.api} == midp2 )
</code>

antenna does not support such thing yet. and if you look into the todo list of the antenna author you will notice that he plans to realize this, but he seems to be not the fastest creating new versions...

perhaps someone of you have a better idea how to solve my problem mentioned above.
currently im using dummy properties this way:


<code>
<condition property="res_176x208" value="true">
   <equals arg1="${res_images}" arg2="176x208"/>
</condition>
</code>

{res_images} contains an identifier for the resource-folder for the images ("176x208"). but because i cant test these values in the preprocessor statements i create a dummy property (whose value is without sense).
then i can test like this

<code>
//#ifdef res_176x208
</code>

i hate that ... really ..
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #3 - Posted 2004-10-13 14:21:18 »

your resource stuff looks like it could be handled by polish:
http://www.j2mepolish.org/index.html

Offline shmoove

Junior Member




Doh!


« Reply #4 - Posted 2004-10-13 14:43:21 »

They way I handle it is with ifdefs in the code:
1  
2  
3  
4  
5  
6  
7  
//#ifdef NOKIAUI
 // use DirectGraphics
//#elifdef MIDP2
 // use MIDP 2.0 features
//#else
 // use MIDP 1.0 features
//#endif


The build script has the following two properties right at the beginning:
1  
2  
<property name="model" value="" />
<property file=".\properties\${model}.properties" />

That file property (the second one) means that properties will be loaded from a file.
Then I have property files for each device class I develop for with the properties for the preprocessor, for example one for the Nokia 6230 might look like this:
1  
2  
3  
pp_symbols=NOKIA,MIDP2,MMAPI
gfx_class=128x128
snd_class=MIDI


And my preprocess task looks like this:
1  
2  
3  
4  
<target name="preprocess" depends="initialize">
  <echo message="Preprocessing with the following symbols: ${pp_symbols}" />
  <wtkpreprocess  srcdir="${ppsrc.dir}"  destdir="${src.dir}" symbols="${pp_symbols}" />
</target>

Now anything in the pp_symbols part of the file is defined, so the preprocessor knows what parts to put in and what to leave out.

As for the resources, it's similar. I have a property in the build script to define the directory from where resources should be taken:
1  
2  
<property name="gfx.dir" location="${gfx_class}"/>
<property name="snd.dir" location="${snd_class}"/>


In the package task I add a fileset property to include the appropiate directories:
1  
2  
<fileset dir="${gfx.dir}"/>
<fileset dir="${snd.dir}"/>

So that the appropiate directories get packaged with the jar.

Now all I have to do is run ant with a -Dmodel={the name of the appropiate property file}, and everything from then on is automatic.

shmoove
Offline MOHK

Junior Newbie





« Reply #5 - Posted 2006-01-10 14:08:56 »

huh preprocessor 'Fcource ArcanumX2
Platform indepentend ...
try it + ECLIPSE ( don't get adicted Smiley )
Offline Anon666

Junior Member




aka Abuse/AbU5e/TehJumpingJawa


« Reply #6 - Posted 2006-01-11 01:41:00 »

I suggest steering well clear of preprocessors.

There are publishers whose coding standards explicitly prohibit the use of them, and for good reason too.

In my personal experience preprocessed code becomes unmaintainable in a very short space of time,

Trivial examples such as :-
1  
2  
3  
4  
5  
6  
7  
//#ifdef NOKIAUI
// use DirectGraphics
//#elifdef MIDP2
// use MIDP 2.0 features
//#else
// use MIDP 1.0 features
//#endif


Already begin to show the problem of preprocessors.
For example, apply the above example to the area of Sound playback.
You will need different code for :-

- Nokia midp1,
- Nokia midp2, (with subtle but critical differences between 6600, 7650, 6230i, and a host of others)
- O2,
- Samsung, (both using the Samsung API, and using midp2. Again, both implementations will require subtle differences for various devices)
- Vodafone,
- Siemens,
- Motorola, (several different variants would be required)
- NEC,
- LG,
- Sagem,
- SonyEricsson, (atleast 2 variants would be required)

The list goes on and on!

And this is covering just the single aspect of sound playback!
Move onto any of the other areas that require changes when porting a game,
or address API bugs that appear on a per-device (or even per-firmware) basis
and the numbers of preprocessor statements balloons enormously.

I have seen games where there are more lines of preprocessor statements than lines of game code!!
At this stage, the code might as well be junked, as it has no value what-so-ever.

Basically, preprocessors are not scalable. They appear to be an adequate solution when you have to worry about just ~3 tiers of device -
but when the reality appears that you need to support upward of 100 devices, preprocessors are completely useless.


I wish I could elaborate on the alternative, but I would be in breach of my contract and would almost certainly get fired Roll Eyes
Offline OverKill

Junior Member




Java games rock!


« Reply #7 - Posted 2006-01-11 10:34:36 »

Exactly the reason my comp does not use Antenna, Eclipse or Netbeans.
We require a preproccessor and since they (along with other problems) stand in conflict to above we just don't use them.
Not pretty but UltraEdit and GNU work great.
Offline OverKill

Junior Member




Java games rock!


« Reply #8 - Posted 2006-01-11 11:02:15 »

I suggest steering well clear of preprocessors.

There are publishers whose coding standards explicitly prohibit the use of them, and for good reason too.
You have a publisher for J2ME games?
Or do you mean Java-Verified?

Quote
In my personal experience preprocessed code becomes unmaintainable in a very short space of time,
Unless the person knows what they are doing, definetly not so.
While there are problems in the j2me landscape they will be there no matter what system you use.
F.i. my comp supports 60+ device groups ... I'd hate to imagine how it would be without a precompiler.
Not to mention the size, as using a precompiler will simply remove code so it is never passed to the compiler.

Quote
Trivial examples such as :-
1  
2  
3  
4  
5  
6  
7  
//#ifdef NOKIAUI
// use DirectGraphics
//#elifdef MIDP2
// use MIDP 2.0 features
//#else
// use MIDP 1.0 features
//#endif

1. can you 'define' stuff with antenna or use includes?
2. using 'features' is a sure path to getting yourself into a LOT of problems.

Quote
Already begin to show the problem of preprocessors.
For example, apply the above example to the area of Sound playback.
You will need different code for :-

- Nokia midp1,
- Nokia midp2, (with subtle but critical differences between 6600, 7650, 6230i, and a host of others)
- O2,
- Samsung, (both using the Samsung API, and using midp2. Again, both implementations will require subtle differences for various devices)
- Vodafone,
- Siemens,
- Motorola, (several different variants would be required)
- NEC,
- LG,
- Sagem,
- SonyEricsson, (atleast 2 variants would be required)

The list goes on and on!
Same problems you have with or without preprocessors.

Quote
And this is covering just the single aspect of sound playback!
Move onto any of the other areas that require changes when porting a game,
or address API bugs that appear on a per-device (or even per-firmware) basis
and the numbers of preprocessor statements balloons enormously.
Once the system is setup porting is quite easy.

Quote
I have seen games where there are more lines of preprocessor statements than lines of game code!!
At this stage, the code might as well be junked, as it has no value what-so-ever.
And I have seem games that were so horribly bloated it is a wonder they actually got the game in the jar!

The problem often lies with the programmers and not with the tools.
Anyone can write horrible code! But we do not blame Java for it do we?

Quote
Basically, preprocessors are not scalable. They appear to be an adequate solution when you have to worry about just ~3 tiers of device -
but when the reality appears that you need to support upward of 100 devices, preprocessors are completely useless.
Wrong!
You simply need to do some software engineering. Preprocessors are very flexible and powerfull.
Again, programmers are mostly at fault. I know my share of people that take the easy way and do exactly as you say. It is missleading to blame the tool for the user screwing up!

I know other companies that have other interresting ways of porting.
They copy the project and then change what needs to be changed.
So for every game they have, in case of 100 devices, 100 different versions!

Quote
I wish I could elaborate on the alternative, but I would be in breach of my contract and would almost certainly get fired Roll Eyes
Hehe same here. Wink
Offline Anon666

Junior Member




aka Abuse/AbU5e/TehJumpingJawa


« Reply #9 - Posted 2006-01-11 11:22:10 »

Quote
I know other companies that have other interresting ways of porting.
They copy the project and then change what needs to be changed.
So for every game they have, in case of 100 devices, 100 different versions!

hehe, that sounds like jamdat's porting strategy.

Quote
Not to mention the size, as using a precompiler will simply remove code so it is never passed to the compiler.

A solution without a preprocessor does not imply an increase in code size.
Infact, size *reductions* are typically the case.
An optimal MIDlet should not have more than 2 classes. (except where there is a device limitation on max. class file size e.g. some of the Panasonics)

Quote
Wrong!
You simply need to do some software engineering. Preprocessors are very flexible and powerfull.

It is clear we differ in opinion, and the only way to convince you otherwise would be to expose corporate knowledge - so we will have to agree to differ.

Quote
Once the system is setup porting is quite easy.

Suffice to say, the ultimate aim is to make porting a zero effort task.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline OverKill

Junior Member




Java games rock!


« Reply #10 - Posted 2006-01-11 11:25:55 »

I wish I could elaborate on the alternative, but I would be in breach of my contract and would almost certainly get fired Roll Eyes
Rapid-M?
The ever mysterious software everyone has heard about but no one knows a thing?
Offline Anon666

Junior Member




aka Abuse/AbU5e/TehJumpingJawa


« Reply #11 - Posted 2006-01-11 21:24:06 »

Exactly the reason my comp does not use Antenna, Eclipse or Netbeans.
We require a preproccessor and since they (along with other problems) stand in conflict to above we just don't use them.
Not pretty but UltraEdit and GNU work great.

What do you use for a runtime debugger?
Do you have code completion?
or code navigation?
or refactoring?
How about syntax checking?

Are you saying you go without all the features of modern IDEs?

The impact in productivity from not using an IDE such as Eclipse or Netbeans is beyond calculation.
Offline OverKill

Junior Member




Java games rock!


« Reply #12 - Posted 2006-01-12 09:11:32 »

Exactly the reason my comp does not use Antenna, Eclipse or Netbeans.
We require a preproccessor and since they (along with other problems) stand in conflict to above we just don't use them.
Not pretty but UltraEdit and GNU work great.
What do you use for a runtime debugger?
Mostly the command line but we also eclipses debugger.
Though the debugger is a little pain because it uses preproccessed code.

Quote
Do you have code completion?
UE has a basic system but nothing more.
The problem is that code completion relies on a library but, like you said earlyer, we have multiple libs.
Classes available in one lib might not be available in another lib, or be a little different or be elsewhere (siemens loves to do that).
I doubt any IDE 'out of the box' would support multiple libraries with an appropriate interface and whatnot.

Quote
or code navigation?
UE supports that more or less.

Quote
or refactoring?
nothing beyond a search&replace, which seems to be quite enough.

Quote
How about syntax checking?
Nothing, that is not really a problem.

Quote
Are you saying you go without all the features of modern IDEs?
Well UE does support a lot of stuff.

Quote
The impact in productivity from not using an IDE such as Eclipse or Netbeans is beyond calculation.
If we were in a regular programming environment I'd agree. (I use Eclipse at home mainly)
But this is J2ME + vendor libs.
Actually if anything I'd say the biggest loss would be the debugger. But we have made changes to our tools to compensate that.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

ctomni231 (33 views)
2014-07-18 06:55:21

Zero Volt (29 views)
2014-07-17 23:47:54

danieldean (24 views)
2014-07-17 23:41:23

MustardPeter (26 views)
2014-07-16 23:30:00

Cero (41 views)
2014-07-16 00:42:17

Riven (43 views)
2014-07-14 18:02:53

OpenGLShaders (31 views)
2014-07-14 16:23:47

Riven (30 views)
2014-07-14 11:51:35

quew8 (29 views)
2014-07-13 13:57:52

SHC (65 views)
2014-07-12 17:50:04
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!