ENIGMA Forums

General fluff => Announcements => Topic started by: Josh @ Dreamland on May 12, 2010, 08:00:05 am

Title: Fixed those Makefiles
Post by: Josh @ Dreamland on May 12, 2010, 08:00:05 am
Good news everyone. I got the makefiles not to recompile all the time. I've not yet committed my changes though; be patient. I want to make sure all the changes I've made to the syntax checker and parser hold up during some field testing, and there's some code that needs moved around because it's being called too often.

Anyway, I'm not sure I can enumerate all the changes between my next revision (expect it tonight) and my last; that's why we have Diff.

The IRC has relieved me of the things I usually keep in a list to say when I make a newspost, especially with freezway asking how makefiles are coming every twenty minutes. Freezway, the makefiles work, but you can't have them. So there.

I may as well share concerns as well as success. I decided to use makefiles, despite them being an ancient art that's a huge pain to get working, because I wanted individual systems to be responsible for their own rules of building. This would be especially helpful, I thought, when we did the Wii port, which is necessarily Make-based. Problem is, I'm not sure what changes would need made to the makefile (particularly the ones under SHELL/ and SHELL/Universal_System/) to enable the modified Make to compile it correctly. I will need to thoroughly inspect the Wii-written makefiles for things that need set.

The most glaringly obvious of these is that $(DEVKITPPC) needs set, and that it includes a file called wii_rules from that directory. This leaves a number of questions that I can't yet answer with certainty. Namely, do I want to make it so that every system relies on a file called $(COMPILER_DATA)/$(PLATFORMNAME)_rules? Do I want to just include makefiles/makefile.$(PLATFORMNAME)?

It seems the latter would be the simplest as well as the most easily extended since as many files can be dumped into that folder as the OS allows, and the makefile will include any of them LGM/ENIGMA request by name or fragment of name (wii, pc, etc). It is what I will likely be going with unless someone has a better idea.

That leaves one additional problem that needs dealt with for a number of reasons. How do we incorporate multiple compilers? Currently, ENIGMA frantically searches for c++ and g++ at load time. If it doesn't find them, it errors to Ism, who asks the user. Either way, it leaves knowing where gcc and make/mingw32-make are located. That location name can be made into a map, certainly. But, where do we store compiler information? A new folder, ENIGMAsystem/compilers/?  A new text file, ENIGMAsystem/compilers? The former would be more desirable so that, should compilers be pluginized (and this is thinking way ahead), plugins aren't fighting for permissions and last word in one text file, and aren't iterating it on and off for their input. It would just rely--as the entire remainder of the system would, really--on no two compilers sharing a name.

Perhaps all that belongs in Proposals anyway, I guess I just needed something to put in this newspost. Maybe I'll post it there later.

Anyway, real work to do now.
Cheers.
Title: Re: Fixed those Makefiles
Post by: The 11th plague of Egypt on May 12, 2010, 10:52:29 am
Isn't your Political science exam tomorrow? You should postpone the release and sleep or study.

Good luck.
Title: Re: Fixed those Makefiles
Post by: freezway on May 12, 2010, 05:21:49 pm
=)
Title: Re: Fixed those Makefiles
Post by: retep998 on May 12, 2010, 11:37:21 pm
Now you just need to fix the alternative that us windows users need since we don't have make XD
Title: Re: Fixed those Makefiles
Post by: kkg on May 13, 2010, 08:03:00 am
@retep998
Can't josh make it so ENIGMA does the make stuff itself, regardless of the OS it's on? Wouldn't know, just guessing.
Title: Re: Fixed those Makefiles
Post by: Josh @ Dreamland on May 13, 2010, 08:21:08 am
kkg:
I did so in R3 where the only compiler we'd be using was the native GCC, but accounting for the Wii, I realized we would need makefiles at some point. I still didn't want to, so I considered the full set of benefits and flaws that would come with it;

Flaws:
- Labor. Oooh, labor.
Benefits:
- Any system under Platforms/ or Graphics_Systems/ could be compiled without ENIGMA even knowing they exist.
- - - This means that more systems could be added without any further hard-coding in the compiler.
- Make would enable compilation for more fragile systems, such as the Wii, which always use makefiles to get the job done right.
- Make would ultimately handle dependency resolution for me, compiling only what needed to be (as it does now).

At that point, it was clear that whatever work it took to learn make and write makefiles, even for newer systems down the road, it'd be worth it.
So I went the extra mile and wrote a shell script to write makefiles for me/other developers.

Also, it should correctly locate Make on Windows now, if anyone would bother to test 218.
Title: Re: Fixed those Makefiles
Post by: IsmAvatar on May 13, 2010, 11:02:25 am
Code: [Select]
ismavatar@mage-ubuntu:~/enigma-dev$ svn up
...
Updated to revision 218.
ismavatar@mage-ubuntu:~/enigma-dev$ make
cd CompilerSource && make
make[1]: Entering directory `/home/ismavatar/enigma-dev/CompilerSource'
mkdir .eobjs
g++ -Wall   -fPIC -c  cfile_parse/cfile_parse.cpp      -o .eobjs/cfile_parse.o
make[1]: Leaving directory `/home/ismavatar/enigma-dev/CompilerSource'
ismavatar@mage-ubuntu:~/enigma-dev$

Make only compiled one object file, and I'm not seeing any kind of dll/so to work with here. Had to use the old method of C::B to get me an so.

Code: [Select]
ismavatar@mage-ubuntu:~/enigma-dev$ java -jar lgm16b4.jar
Java Version: 10600 (1.6.0_20)
Loading lib files in /home/ismavatar/enigma-dev/lgm16b4.jar
01_move.lgl 02_main1.lgl 03_main2.lgl 04_control.lgl
 05_score.lgl 06_extra.lgl 07_draw.lgl
SvnKit missing, corrupted, or unusable. Please download and place next to the enigma plugin in order to enable auto-update.
Initializing Enigma: Intializing Parsers.Probing for GCC...
GCC located. Path: `'
Successfully loaded GCC definitions
Undefining _GLIBCXX_EXPORT_TEMPLATE
# 1 "blank.txt"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "blank.txt"
7dirs:
"/usr/include/c++/4.4/"
"/usr/include/c++/4.4/i486-linux-gnu/"
"/usr/include/c++/4.4/backward/"
"/usr/local/include/"
"/usr/lib/gcc/i486-linux-gnu/4.4.3/include/"
"/usr/lib/gcc/i486-linux-gnu/4.4.3/include-fixed/"
"/usr/include/"
All that worked. Trying to find make.
cd CompilerSource && make
make[1]: Entering directory `/home/ismavatar/enigma-dev/CompilerSource'
make[1]: `.eobjs/cfile_parse.o' is up to date.
make[1]: Leaving directory `/home/ismavatar/enigma-dev/CompilerSource'
Good news; it should seem I can reach make from `make'
Ignoring error in specialization expression at position 19: Expected operator at this point

Ignoring error in specialization expression at position 19: Expected operator at this point

Ignoring error in specialization expression at position 23: Expected operator at this point

Successfully parsed ENIGMA's engine (570ms)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Initializing EDL Parser... Done.
Unable to load plugin: jna.jar: null: Missing plugin entry point (LGM-Plugin)

I then clicked Enigma->Run and discovered that it's about time for LGM to start threading...

Code: [Select]
Location in memory of structure: 0x94fed78
File version: 600

COPYING SOME FUCKING RESOURCES:
Copying sprite names [0]
Copying sound names [0]
Copying background names [0]
Copying path names [kidding, these are totally not implemented] [0]
Copying script names [0]
Copying font names [kidding, these are totally not implemented] [0]
Copying timeline names [kidding, these are totally not implemented] [0]
Copying object names [0]
Copying room names [0]
SYNTAX CHECKING AND PRIMARY PARSING:
0 Scripts:
"Linking" scripts
`Linking' 0 scripts in 0 passes...
Completing script "Link"
Done.
0 Objects:
"Linking" scripts into the objects...
"Link" complete.
# Target takes the following parameters:
#   GMODE{run,build,debug,compile}
#   GRAPHICS{<anything under graphics_systems>}
#   PLATFORM{<anything under platforms>}
#   GLINKS{<requirements of anything above>}
echo Okay.
Okay.
cd ENIGMAsystem/SHELL/ && make GMODE=Run GLINKS="-lGL -lz" GRAPHICS=OpenGL PLATFORM=xlib
make[1]: Entering directory `/home/ismavatar/enigma-dev/ENIGMAsystem/SHELL'
# Target takes the following parameters:
#   GMODE{run,build,debug,compile}
#   GRAPHICS{<anything under graphics_systems>}
#   PLATFORM{<anything under platforms>}
#   GLINKS{<anything needed by the above as linker args>}
cd Graphics_Systems/OpenGL/    && make Run MODE=Run
make[2]: Entering directory `/home/ismavatar/enigma-dev/ENIGMAsystem/SHELL/Graphics_Systems/OpenGL'
mkdir .eobjs_Run
g++ -c graphics_object.cpp      -o .eobjs_Run/graphics_object.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/GSblend.o] Error 1 (ignored)
g++ -c GSblend.cpp      -o .eobjs_Run/GSblend.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/GScolors.o] Error 1 (ignored)
g++ -c GScolors.cpp      -o .eobjs_Run/GScolors.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/GSenable.o] Error 1 (ignored)
g++ -c GSenable.cpp      -o .eobjs_Run/GSenable.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/GSmiscextra.o] Error 1 (ignored)
g++ -c GSmiscextra.cpp      -o .eobjs_Run/GSmiscextra.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/GSprmtvs.o] Error 1 (ignored)
g++ -c GSprmtvs.cpp      -o .eobjs_Run/GSprmtvs.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/GSscreen.o] Error 1 (ignored)
g++ -c GSscreen.cpp      -o .eobjs_Run/GSscreen.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/GSspriteadd.o] Error 1 (ignored)
g++ -c GSspriteadd.cpp      -o .eobjs_Run/GSspriteadd.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/GSsprite.o] Error 1 (ignored)
g++ -c GSsprite.cpp      -o .eobjs_Run/GSsprite.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/GSstdraw.o] Error 1 (ignored)
g++ -c GSstdraw.cpp      -o .eobjs_Run/GSstdraw.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/GSsurface.o] Error 1 (ignored)
g++ -c GSsurface.cpp      -o .eobjs_Run/GSsurface.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/OPENGLStd.o] Error 1 (ignored)
g++ -c OPENGLStd.cpp      -o .eobjs_Run/OPENGLStd.o
mkdir .eobjs_Run/
mkdir: cannot create directory `.eobjs_Run/': File exists
make[2]: [Run] Error 1 (ignored)
make[2]: Leaving directory `/home/ismavatar/enigma-dev/ENIGMAsystem/SHELL/Graphics_Systems/OpenGL'
cd Platforms/xlib/       && make Run MODE=Run
make[2]: Entering directory `/home/ismavatar/enigma-dev/ENIGMAsystem/SHELL/Platforms/xlib'
mkdir .eobjs_Run
g++ -c XLIBmain.cpp      -o .eobjs_Run/XLIBmain.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/XLIBwindow.o] Error 1 (ignored)
g++ -c XLIBwindow.cpp      -o .eobjs_Run/XLIBwindow.o
mkdir .eobjs_Run/
mkdir: cannot create directory `.eobjs_Run/': File exists
make[2]: [Run] Error 1 (ignored)
make[2]: Leaving directory `/home/ismavatar/enigma-dev/ENIGMAsystem/SHELL/Platforms/xlib'
cd Universal_System/         && make Run MODE=Run
make[2]: Entering directory `/home/ismavatar/enigma-dev/ENIGMAsystem/SHELL/Universal_System'
mkdir .eobjs_Run
g++ -c CallbackArrays.cpp      -o .eobjs_Run/CallbackArrays.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/collisions.o] Error 1 (ignored)
g++ -c collisions.cpp      -o .eobjs_Run/collisions.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/collisions_object.o] Error 1 (ignored)
g++ -c collisions_object.cpp      -o .eobjs_Run/collisions_object.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/compression.o] Error 1 (ignored)
g++ -c compression.cpp      -o .eobjs_Run/compression.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/EGMstd.o] Error 1 (ignored)
g++ -c EGMstd.cpp      -o .eobjs_Run/EGMstd.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/ENIGMA_GLOBALS.o] Error 1 (ignored)
g++ -c ENIGMA_GLOBALS.cpp      -o .eobjs_Run/ENIGMA_GLOBALS.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/estring.o] Error 1 (ignored)
g++ -c estring.cpp      -o .eobjs_Run/estring.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/events.o] Error 1 (ignored)
g++ -c events.cpp      -o .eobjs_Run/events.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/event_system.o] Error 1 (ignored)
g++ -c event_system.cpp      -o .eobjs_Run/event_system.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/globalupdate.o] Error 1 (ignored)
g++ -c globalupdate.cpp      -o .eobjs_Run/globalupdate.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/IMGloading.o] Error 1 (ignored)
g++ -c IMGloading.cpp      -o .eobjs_Run/IMGloading.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/instance.o] Error 1 (ignored)
g++ -c instance.cpp      -o .eobjs_Run/instance.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/mathnc.o] Error 1 (ignored)
g++ -c mathnc.cpp      -o .eobjs_Run/mathnc.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/OBJaccess.o] Error 1 (ignored)
g++ -c OBJaccess.cpp      -o .eobjs_Run/OBJaccess.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/object.o] Error 1 (ignored)
g++ -c object.cpp      -o .eobjs_Run/object.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/objecttable.o] Error 1 (ignored)
g++ -c objecttable.cpp      -o .eobjs_Run/objecttable.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/planar_object.o] Error 1 (ignored)
g++ -c planar_object.cpp      -o .eobjs_Run/planar_object.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/reflexive_types.o] Error 1 (ignored)
g++ -c reflexive_types.cpp      -o .eobjs_Run/reflexive_types.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/roomsystem.o] Error 1 (ignored)
g++ -c roomsystem.cpp      -o .eobjs_Run/roomsystem.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/simplecollisions.o] Error 1 (ignored)
g++ -c simplecollisions.cpp      -o .eobjs_Run/simplecollisions.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/spriteinit.o] Error 1 (ignored)
g++ -c spriteinit.cpp      -o .eobjs_Run/spriteinit.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/spritestruct.o] Error 1 (ignored)
g++ -c spritestruct.cpp      -o .eobjs_Run/spritestruct.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/transform_object.o] Error 1 (ignored)
g++ -c transform_object.cpp      -o .eobjs_Run/transform_object.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/var_cr3.o] Error 1 (ignored)
g++ -c var_cr3.cpp      -o .eobjs_Run/var_cr3.o
mkdir .eobjs_Run
mkdir: cannot create directory `.eobjs_Run': File exists
make[2]: [.eobjs_Run/WITHconstruct.o] Error 1 (ignored)
g++ -c WITHconstruct.cpp      -o .eobjs_Run/WITHconstruct.o
mkdir .eobjs_Run/
mkdir: cannot create directory `.eobjs_Run/': File exists
make[2]: [Run] Error 1 (ignored)
make[2]: Leaving directory `/home/ismavatar/enigma-dev/ENIGMAsystem/SHELL/Universal_System'
g++ SHELLmain.cpp Graphics_Systems/OpenGL/.eobjs_Run/*.o Platforms/xlib/.eobjs_Run/*.o Universal_System/.eobjs_Run/*.o -lGL -lz -o game.exe
make[1]: Leaving directory `/home/ismavatar/enigma-dev/ENIGMAsystem/SHELL'
+++++Make completed successfully.++++++++++++++++++++++++++++++++++++
No resource data in exe
Game returned 0
0 Sprites:
0 Sounds:
0

After which I was greeted with a game window (default).

Ok, someone's going to have to explain to me how to add scrollbars to that thing, because [ codebox ] doesn't work.

Also, one of these days you'll have to give me the new Enigma/LateralGM background tile, because I never got a copy of it.
Title: Re: Fixed those Makefiles
Post by: Josh @ Dreamland on May 13, 2010, 02:30:16 pm
Ism:
I'm not sure if Retro's makefile could magically discern what OS you are on, but mine can't. From the main directory's makefile, call make ENIGMA PLATFORM=linux.

And yes, threading and console output would be nice. If you like, I can prefix messages to redirect with "enigma: ".
Don't worry, compile is only slow the first time, then it completes in seconds.
Title: Re: Fixed those Makefiles
Post by: luiscubal on May 13, 2010, 03:56:59 pm
Quote
I'm not sure if Retro's makefile could magically discern what OS you are on, but mine can't.
That might be a feature, rather than a bug, if you consider cross-compilation. A lot of software is hard-coded to compile for the platform it is running on, which is not always what one want, and it is painful to change platforms.

Unless, of course, it would detect and use the current OS as the default platform, but you could override that.

Related:
http://stackoverflow.com/questions/714100/os-detecting-makefile

Also, for multi-core computers, you may want to try the make -j(-j 2 on dual cores, -j 4 on quad cores, etc.) flag to make it faster.
Title: Re: Fixed those Makefiles
Post by: freezway on May 13, 2010, 05:20:19 pm
i usually use -j5
Title: Re: Fixed those Makefiles
Post by: Josh @ Dreamland on May 13, 2010, 10:38:54 pm
You know, few things are more annoying than your OS dying because Java really blows on it.
Title: Re: Fixed those Makefiles
Post by: freezway on May 14, 2010, 12:17:41 am
does ctrl-alt-bksp work?
Title: Re: Fixed those Makefiles
Post by: kkg on May 14, 2010, 01:33:20 am
@freezway
I love doing that to the computers that use X at the local shops :P Watching the employees try to figure out what's wrong is priceless
Title: Re: Fixed those Makefiles
Post by: Josh @ Dreamland on May 14, 2010, 08:04:12 am
You have local shops with computers running X? Most people around here don't really know what Linux is...
Title: Re: Fixed those Makefiles
Post by: kkg on May 14, 2010, 10:49:21 am
By local shops I mean Harvey Norman, with their display of Netbooks, a few of which don't have the capability of running anything other than X :P
Title: Re: Fixed those Makefiles
Post by: IsmAvatar on May 14, 2010, 09:53:46 pm
I don't understand. That just restarts X and takes you to the login screen.

Also, if Java freezes up and you don't want to log out, use [Ctrl]+Alt+F1 (or any F-key from 1 to 6), give your credentials, and then $ pkill java
Title: Re: Fixed those Makefiles
Post by: Josh @ Dreamland on May 14, 2010, 10:01:44 pm
That doesn't help the shit-my-entire-computer-is-frozen-because-java-killed-X problem.
Title: Re: Fixed those Makefiles
Post by: freezway on May 14, 2010, 10:54:25 pm
do u know why LGM makes java kill it?
Title: Re: Fixed those Makefiles
Post by: Josh @ Dreamland on May 14, 2010, 11:11:49 pm
It's some Java bug (Ism says it's actually an X bug, but I blame Java as well since nothing else kills X) invoked when a drag and drop tile is released.
Title: Re: Fixed those Makefiles
Post by: Micah on May 15, 2010, 12:01:32 pm
Wow. You're seriously assuming that Java has a bug before assuming that X has a bug?
Title: Re: Fixed those Makefiles
Post by: luiscubal on May 15, 2010, 01:39:47 pm
Relevant bug trackers:
http://bugs.sun.com/view_bug.do?bug_id=6397447
https://bugs.freedesktop.org/show_bug.cgi?id=17126

Forums:
http://forums.sun.com/thread.jspa?threadID=5319312
Title: Re: Fixed those Makefiles
Post by: IsmAvatar on May 15, 2010, 04:08:33 pm
http://www.ismavatar.com/lgm/forum/index.php?t=11
LGM forum already had a bug filed on this. We realized that it's not a bug with LGM, but seems to be Java-end. The bug is reproduced by having any program with D&D, with a splash screen, running on a specific set of versions of X with specific graphics cards, and only seems to take effect if the program is a JAR. The problem can be worked around either by not using D&D or disabling the splash screen (which can be achieved by modifying the manifest, a text file inside the jar).

Once we realized it wasn't an LGM bug, we moved it from Bugs to Help. It has been an argument between Java and X to figure out whose fault it is. I suspect X.
Title: Re: Fixed those Makefiles
Post by: luiscubal on May 16, 2010, 12:00:28 pm
I don't see how any program should be allowed to freeze X. That specially applies to non-admin users.
Even if it would be acceptable for a program to do that with a lot of effort, doing it "accidentally" makes me automatically consider it a X11 bug, even if Java could possibly work around it.
Title: Re: Fixed those Makefiles
Post by: freezway on May 16, 2010, 12:04:06 pm
so.... whats the plan? wait for a bugfix? buy josh a new puter?
Title: Re: Fixed those Makefiles
Post by: IsmAvatar on May 16, 2010, 12:16:02 pm
LGM has been working around this by encouraging anyone on Linux who believes they may encounter this bug to remove the splash screen from the Manifest file in the jar. We've also considered distributing a version of LGM without the splash screen.

Alternatively, avoid using D&D (consider using alternative functionality, if available), and wait for a bugfix in Java or X. According to one of those pages linked before, a fix is expected in java 6u19 or 6u20. Apparently 6u20 beta still exhibits this problem.

A possible workaround is to apply a binary patch if using 6u18.

Quote
1) find libsplashscreen.so file (on Debian it is in
/usr/lib/jvm/java-6-sun-1.6.0.18/jre/lib/i386/)
2) take your favorite hex editor and starting from 0x70d0 replace 6 bytes to
0x90 0x90 0x90 0x90 0x90 0x90
3) save the file and enjoy.

Use at your own risk, obviously.
Title: Re: Fixed those Makefiles
Post by: Josh @ Dreamland on May 16, 2010, 12:21:57 pm
The splash screen doesn't display here; I assumed you'd removed it.
Title: Re: Fixed those Makefiles
Post by: IsmAvatar on May 16, 2010, 12:27:17 pm
I don't recall removing it. The splash screen not showing up appears to be another bug, actually.
Title: Re: Fixed those Makefiles
Post by: score_under on May 16, 2010, 01:34:36 pm
Wow. You're seriously assuming that Java has a bug before assuming that X has a bug?
(http://enigma-dev.org/forums/avatars/Other/troll5.jpg)
Title: Re: Fixed those Makefiles
Post by: RetroX on May 16, 2010, 02:01:31 pm
Note: the file is supposed to be called "Makefile," not "makefile"

Also, I'm segfaulting in LGM again. :/
Title: Re: Fixed those Makefiles
Post by: Josh @ Dreamland on May 16, 2010, 02:07:11 pm
As a matter of fact, Linux is the only OS they work on at the moment, because Windows can't call make. ^_^
System() can't parse the program name from the arguments.
CreateProcess() can't find mingw32-make.
So really, it only works on Linux at the moment.

Makefile is given priority over makefile; other than that, either is fine.

Only one makefile should be outputting an exe, and it's the one under SHELL. Windows will only run EXE, Linux will run anything given --e permissions. So I used exe.
Title: Re: Fixed those Makefiles
Post by: RetroX on May 16, 2010, 02:14:32 pm
Wow. You're seriously assuming that Java has a bug before assuming that X has a bug?
X doesn't have bugs.  It's just brainfuck to use it and everyone makes bugs by using it.

And as for the EXE extension, yes, it will.  It's just that Nautilus, Dolphin, Thunar, and any other file manager will assume that because it has a .exe extension, it is an EXE, and it will try to run it in WINE.
Title: Re: Fixed those Makefiles
Post by: Josh @ Dreamland on May 16, 2010, 02:16:12 pm
You forgot the :troll:

Also, that's why "Compile" lets you choose the full filename. The 'exe' is meant for ENIGMA to run/work with.
Title: Re: Fixed those Makefiles
Post by: RetroX on May 16, 2010, 02:33:54 pm
Or, you could make your own file extension.

game.enig
Title: Re: Fixed those Makefiles
Post by: luiscubal on May 16, 2010, 03:55:18 pm
Quote
because Windows can't call make.
Quote
CreateProcess() can't find mingw32-make.
Try using the full path.

Quote
lpApplicationName [in, optional]

    The name of the module to be executed. This module can be a Windows-based application. It can be some other type of module (for example, MS-DOS or OS/2) if the appropriate subsystem is available on the local computer.

    The string can specify the full path and file name of the module to execute or it can specify a partial name. In the case of a partial name, the function uses the current drive and current directory to complete the specification. The function will not use the search path. This parameter must include the file name extension; no default extension is assumed.
Title: Re: Fixed those Makefiles
Post by: Josh @ Dreamland on May 16, 2010, 04:45:15 pm
Oh, that was just one of the 600 problems I've encountered on the way. Indented comments were executed; that was a more recent one.

The one I'm dealing with now is that parameters work differently on Windows. make GRAPHICS=OpenGL doesn't work anymore.
Title: Re: Fixed those Makefiles
Post by: luiscubal on May 17, 2010, 01:07:49 pm
What about adding a configuration file?
Then somehow include that file from the make?
Code: [Select]
PLATFORM:=Win32
GRAPHICS:=OpenGL
MODE:=Debug

and in Makefile
Code: [Select]
include config.mk

And call "make". Also has the advantage that as the number of possible configurations increases, the command doesn't get a monster like:
Code: [Select]
make PLATFORM=Win32 GRAPHICS=OpenGL MODE=Debug ENABLE_MMX=true ENABLE_SSE=true USE_GM_STUPID_BEHAVIOR=true USE_GM_STUPID_BEHAVIOR2=true AUDIO_SYSTEM=SDL MODE=2D
I am unsure of the effect configuration files would have on compiling the second time(does changing the file invalidate the whole cache or not?)
Title: Re: Fixed those Makefiles
Post by: Rusky on May 17, 2010, 04:55:22 pm
It doesn't matter how much of a monster the command line is, though- it's just called from within Enigma, so generating it on the fly would be simpler.
Title: Re: Fixed those Makefiles
Post by: Josh @ Dreamland on May 17, 2010, 11:43:26 pm
Indeed. And I could write it to a config file, and may end up doing so later depending on circumstances, but for now it's unnecessary and inconvenient; I'd rather it just worked for now.

Sprites work in R4 now. LGM is odd about its support for importing images with transparency, so be weary. ENIGMA doesn't mind them, however. Now's not the time to benchmark due to debug... scaffolding, we'll call it... left in place. I'll remove it promptly enough.

For now, good night.
Title: Re: Fixed those Makefiles
Post by: IsmAvatar on May 18, 2010, 01:22:49 pm
Also, for those of you checking out r230 or later, you will notice the splash screen has returned.

For those of you experiencing X crashes on Linux when trying to Drag and Drop: Open lgm16b4.jar with a zip manager. Go to META-INF, and edit MANIFEST.MF with a text editor. Remove the Splash Screen line (the 5th line), resave, and update the jar. Sadly, X-crash-fixers will not get to enjoy the Splash Screen, because it was the least intrusive functionality I had to remove in order to stop the X crash. The other options were: Do not jar, disable D&D, or fix X/Java so they play nicely.
You will need to repeat this modification each time the LateralGM jar is replaced, unless I figure out and implement a workaround (seeing as the bug reports offer none at this time after dozens of heads have tried to think of one, I'm going to say the prospects of me finding one are grim).

For those of you not experiencing X crashes, enjoy your splash screen, and laugh politely at the X-crashers.
Title: Re: Fixed those Makefiles
Post by: RetroX on May 18, 2010, 08:12:39 pm
Random thing to note: put an "all" target at the top of the makefile and make it link.  Otherwise, you have to specific "make link" every time. :/

And another thing to note, as I mysteriously found out today:
ld *.o -o all.o -lc
This will link objects together.  Would probably be useful somehow.
Title: Re: Fixed those Makefiles
Post by: Josh @ Dreamland on May 18, 2010, 09:11:13 pm
Retro: All my makefiles use *.o to quickly link. The link target is depended on by Windows' and Linux' targets. The assumption is that you're using one of those. I separated it to avoid reprinting all its dependencies.
Title: Re: Fixed those Makefiles
Post by: IsmAvatar on May 19, 2010, 11:20:39 am
Bug: keyword mod is not implemented.
Workaround: Replace every occurrance of "mod" with "%"

Another Bug: I've encountered a strange issue relating to scope and comparisons of numbers less than or equal to 8. Sorry, it's difficult to simplify any further.
Create event:
Code: [Select]
x = room_width / 2;
y = 0;
nextdir = 180;
direction = 180;
speed = 4;
Normal Step event:
Code: [Select]
if (y == 0) direction = nextdir;
nextdir = 0; //this seems to lose scope before the next step rolls around

//enigma handling code
x += hspeed;
y += vspeed;
Draw event: draw something at x,y so you can see what's going on. The figure should always move right, but seems to always move left.

Also, to add to the strange behavior, set y to 24, and then in the step even replace if (y == 0) with if (y == 24). You'll notice it now moves right. In fact, any value greater 8 will work properly. Set it to any number from 0 through 8, and it will lose scope.

Workaround: In the create event, prefix nextdir with "var ", such that it becomes "var nextdir = 180;"
Title: Re: Fixed those Makefiles
Post by: Josh @ Dreamland on May 19, 2010, 05:34:04 pm
Well, mod is easily fixed by--and this needs done soon anyway--creating a file of syntax quirks and in it placing #define mod %. I will do that soon enough; but it won't work for everything because the syntax checker doesn't actually unroll macros yet, even though everything else does.

I'm not sure what's causing your other bugs, Ism, if they are bugs at all. We'll check the outputted C++ next we talk.
Title: Re: Fixed those Makefiles
Post by: IsmAvatar on May 19, 2010, 06:02:27 pm
I already checked the C++. It looks almost exactly the same as the code I put above. Like I said, it sounds like some sort of scope problem, with odd behavior for comparisons on values <= 8.
Title: Re: Fixed those Makefiles
Post by: Josh @ Dreamland on May 19, 2010, 06:56:25 pm
Scratch that. As it happens, sin(180*pi/180) = 1.2246063538223773e-16.

GM implemented a threshold for such in its == operators. I guess ENIGMA will have to do the same. Morbidly disappointing, really.
Title: Re: Fixed those Makefiles
Post by: Rusky on May 19, 2010, 07:34:49 pm
yay floating point
Title: Re: Fixed those Makefiles
Post by: freezway on May 19, 2010, 07:58:38 pm
i can make my calc say 1*5 = 5.000000001 b/c it keeps 14 digits of precision but displays 9
Title: Re: Fixed those Makefiles
Post by: retep998 on May 19, 2010, 08:15:15 pm
My calc store integers and fractions as bignum and boy can they get big.
Around 2 to the 2200 power or so.
It can even calculate primes faster than my c++ programs XD
Title: Re: Fixed those Makefiles
Post by: IsmAvatar on May 19, 2010, 11:18:30 pm
Ah, ok. I'll work around it.
Title: Re: Fixed those Makefiles
Post by: luiscubal on May 20, 2010, 06:54:00 am
Floating point equality comparison is considered harmful by programmers who had to work with it.
Stuff like 0.2+0.2+0.2+0.2+0.2 == 1.0 outputting false in most programming languages(including Java and C++, apparently). Not sure if it's that particular example or something else, but it was something similar.
Title: Re: Fixed those Makefiles
Post by: Josh @ Dreamland on May 20, 2010, 08:16:05 am
luis, flexaplex:
Mark decided he'd take a different approach to the woeful inadequacy of computers' floating point capabilities. While it is true that most languages cannot correctly compare fifths/tenths added together (it is a repeating decimal in binary and therefore can not be represented in a single string of bits of any size), or that sin(pi) == 0 (it's actually 1.2246063538223773e-16), Mark decided that GM should have that capability. That being the case, he made his comparison operators not compare the entire double.

If GM evaluates 1.0000000000001 > 1 as false, Mark is an idiot. ENIGMA will evaluate 1.0000000000001 > 1 and 1.000000000000001 > 1 as true, 1.0000000000000001 > 1 as false. This is because 1.0000000000000001 is simply outside the precision of a floating point value. In actuality, both ENIGMA and GM will store more bits of precision than they check, which is all the solution really needs at this point.


Because of this, I was going to replicate the behavior in ENIGMA by casting to float before comparisons. IEEE tells us that this isn't as simple as just chopping off a large part of the significand, since doubles implement larger exponents as well. But I'm assuming FPUs have a special path just for the occasion.
Title: Re: Fixed those Makefiles
Post by: luiscubal on May 20, 2010, 09:20:18 am
Floating point handling is dangerous.
I believe GCC tries to "optimize out" those x > y statements(since they are about constants). GCC uses a huge-precision math library during compilation, so 1.0000000000000001 > 1 will probably be just optimized to true, even if we were talking of a precision of only 3 digits in the final executable.
Hopefully, your edge cases were pretty superficial, so there shouldn't be a problem with GCC optimizing it to give the correct result, but be aware that different compilers(even different compiler versions) and different optimizers behave differently.
Even if today your GCC version works, tomorrow an user updates his/her version and everything suddenly stops working.

This is not a problem to be underestimated.
(btw, just curious: does GM use ordinary binary floating point or does it use decimal floating point?)
Title: Re: Fixed those Makefiles
Post by: score_under on May 22, 2010, 07:27:36 am
(btw, just curious: does GM use ordinary binary floating point or does it use decimal floating point?)
Uses double.