How do I use Brucey's goodies?
BlitzMax Forums/Brucey's Modules/How do I use Brucey's goodies?
| ||
| I built BMK-NG and BCC, put those (with core.bmk and make.bmk) in the bin folder, and replaced the BRL.Mod and Pub.Mod (had to remove MaxGUI - something about Win32MaxGuiEx) So all of the modules build fine (MinGW G++ v. 4.8.1-4) but when I go to compile anything, it kicks back "Syntax Error - Expecting Identifier" on file "pub.mod/freejoy.mod/freejoy.debug.win32.x86.i" The error is all the way on the bottom line, where it says "joy_hits%&[,]&=mem:p("pub_freejoy_joy_hits")" Edit: and another aparently in pub.mod/stdc.mod/stdc.c Full BlitzMax Output: Building untitled1 Compiling:untitled1.bmx Compile Error: Syntax error - expecting identifier. [C:/DevTools/BlitzMax/mod/pub.mod/freejoy.mod/freejoy.debug.win32.x86.i;61;0] Linking:untitled1.debug.exe C:/DevTools/BlitzMax/mod/pub.mod/stdc.mod/stdc.debug.win32.x86.a(stdc.c.debug.win32.x86.o): In function `ftell_': C:/DevTools/BlitzMax/mod/pub.mod/stdc.mod/stdc.c:197: undefined reference to `_ftelli64' C:/DevTools/BlitzMax/mod/pub.mod/stdc.mod/stdc.debug.win32.x86.a(stdc.c.debug.win32.x86.o): In function `fseek_': C:/DevTools/BlitzMax/mod/pub.mod/stdc.mod/stdc.c:193: undefined reference to `_fseeki64' Build Error: Failed to link C:/DevTools/BlitzMax/tmp/untitled1.debug.exe Process complete Any ideas? |
| ||
| - did you use bmx-ng/brl.mod and bmx-ng/pub.mod or did you copy them from SVN or github.com/maxmods? bye Ron |
| ||
| bmx-ng/brl.mod and bmx-ng/pub.mod. Also should add that I am on Windows 10 developer preview - not sure if that would make a difference. Edit: Okay _ftelli64 and _fseeki64 being undefined I believe are issues with MinGW. For now, I changed _fseeki64 to _lseeki64 and _ftelli64 to _telli64 in stdc.c Now I only have the FreeJoy error Since I am on Windows 10 x64 should I be using MinGW64? |
| ||
| It seems some versions of msvct don't have _ftelli64 - who would have known!? There's a way around it with _telli64 and _fileno, so I'll look into fixing those to use the old functions instead. |
| ||
| Thanks Brucey! Once I changed _fseeki64 and _ftelli64, the program was able to compile and run. But after a second, it still crashed saying "expecting identifier" in freejoy.debug.win32.x86.i
joy_hits%&[,]&=mem:p("pub_freejoy_joy_hits")
Any ideas? |
| ||
| Any ideas? Looks like a multi-dimensional array bug with the parser. Thanks for testing ;-) |
| ||
 :_) |
| ||
| BlitzMax in 64-bit. Who da' thunk it? ;-) |
| ||
| BlitzMax in 64-bit. Who da' thunk it? ;-) I Haven't ben able to get any of it to work yet myself -- I got bmk_ng, bcc_ng, modified pub.mod and brl.mod etc. but been unable to compile so far... What download of MinGW do you recommend? |
| ||
| 4.7.1 compiles fine (TDW MinGW ... the "classic" one Brucey uses for many things - and it works with his other modules). Newer ones might work too. - download BCC-NG, compile with vanilla - download BMK-NG, compile with vanilla - copy BCC.exe, BMK.exe, custom.bmk and make.bmk to the "BlitzMaxNG/bin"-folder (config.bmk / custom.bmk / bcc.conf are not needed for "default setups"). then compile all modules via "BlitzMaxNG/bin/bmk.exe -makemods -a [-r]" (-r for release - later you could do a -d for debug too). If errors occour ("mingw not found") you need to set the "MINGW"-Environment variable with "SetX" (if newer than XP) or via GUI. What errors do you get? bye Ron |
| ||
| I heartily recommend TDM64 4.8.1 - the latest version on the TDM site. The easiest setup is to create a MinGW32 folder in your BlitzMax folder and drop it in there. Check that no other MinGW's are on the PATH, and it should all *just work* - no copying of bin or lib files required. Note - many of my modules still need tweaks to build, but I've been busy with the compiler and haven't had time to go through them all yet. However, all the stuff in the bmx_ng repo should be working now. DirectX isn't, except for Direct Sound. And the Win32 MaxGUI is broken. |
| ||
| Thanks, will try again tomorrow... Do I also need a particular IDE build? (I'm assuming there is an additional selection to specify whether you want to compile x86 or x64?) |
| ||
| At the moment you'll need to do everything from the command line. I haven't built a new IDE with all the options yet. So by default, everything will be 32-bit if you are using MaxIDE. It's on the (rather long) list of things to do... |
| ||
| Should be fairly easy to add it to "MaxIDE" ... because "vanilla" should not take care of "-g x64" this should mean "backwards compatibility". Maybe one of the "MaxGUI"-enthusiasts forks the offical MaxIDE, changes the needed parts and voila...there we go. Adding scintilla and gtk is another story. @brucey ng/brl.mod and ng/bmk both have open pull requests. If you do not want to include them, decline them, so I could "cleanup" my forks (removing the branches). bye Ron |
| ||
| Ok, finally got it to start compiling modules now, although I did have to make one more tweak to get it to function: It couldn't find gcc.exe without the MinGW environment variable present, explicitly pointing to the MinGW path. (Without that environment variable, gcc -v did work from anywhere, so it definitely was properly in the path ) It's currently going through the handful of modules that are present, hopefully it will finish compiling without further errors. |
| ||
| hehe ... this is the same error I have had here too: - newer than XP: use SetX MINGW c:\path\to\mingw or - all windows systems: use the Systems-Panel to add a new environment variable. This is because "NG" checks for the environmentvariable, it does not relay on the visibility of the "bmk" via the "PATH"-global (just do "echo PATH" in a cmd shows you the current paths). Like Brucey stated in another post: you could copy your MinGW into "BlitzMaxNG/MinGW32" and it would be found automatically, without fiddling around with "environment variables" etc. Maybe we should create some helper-tool which helps then setting up things ... will discuss that with Brucey, maybe I would just create a bunch of useless work hours... bye Ron |
| ||
| Maybe we should create some helper-tool which helps then setting up things ... will discuss that with Brucey, maybe I would just create a bunch of useless work hours... That, or people like me could learn to read. ;-) |
| ||
| Like Brucey stated in another post: you could copy your MinGW into "BlitzMaxNG/MinGW32" and it would be found automatically, without fiddling around with "environment variables" etc. This is the preferred, less-problematic route. I was thinking perhaps it could automagically set the PATH to include MINGW/bin - just to help a bit for those who still choose to do it the "old" way. |
| ||
| Modifying the "path" is not the preferable way - as you then modify user made settings. It is better to include some "help" in bmk - which the error message then refers ("check -help for further information / check -mingwpath for further information"). You do not know why C:\MinGW (or other) is set in the path, as it does not need to be the one intended for BlitzMax, it is better to inform the user what is missing and how to fix (maybe saying "or make it available in /3rdParty/MinGW32"). bye Ron |
| ||
| Ok, I put MinGW inside of a MinGW32 subfolder, removed the MinGW environment variable, recompiled all modules (only pub.mod, brl.mod, sdl.mod and b3d.mod present). Partial success: I can run some of the samples (e.g. flameduck/oldskool2 , flameduck/circlemania, firepaint, starfieldpong) in 32 AND 64 bit mode -- taskmanager shows that it's succesfully running a 64-bit executable in that case. However, others do blow up: Digesteroids, for example, will immediately bomb out with an "EXCEPTION_ACCESS_VIOLATION" as soon as the program opens. Since you've posted a working Windows x64 binary of Digesteroids to the forum before, I'd assume that one should be functional? Or did you tweak your local digesteroids source as well to make it work? |
| ||
| That was tweaked some how ... because "framework" didnt work at that time. For me it does not work too: Building digesteroids Compiling:simplephysics.bmx Compiling:minitimer.bmx Compiling:dynamicgame.bmx Compiling:MathUtil.bmx Compiling:digesteroids.bmx Linking:digesteroids.debug.exe Executing:digesteroids.debug.exe Debugger Error:Invalid scope kind The old "NG"-Code "EAV"s too .. so it must be an issue with some changes... will go back in time now to check it out. Interestingly "samples/demoapp" in my Dig-Framework (github.com/GWRon/Dig.git) works... so it must be something special. EDIT: Ok ... I opened up "digesteroids.bmx". Right before 'Import "simplephysics.bmx" I prepended: Framework Brl.StandardIO Import Brl.LinkedList Import Brl.Math Import Brl.Retro Import Brl.Max2D In "simplephysics.bmx" I appended right after "Strict": Import Brl.LinkedList Import Brl.Math Import Brl.Retro Import Brl.Max2D This way the whole thing did not EAV anymore. Removing "framework" but keeping the imports, leads to crashes too. So where does it crash? "LoadImage(bla)" fails to return a valid image ... something is disturbing the PNG loading (maybe multiple libpng ?), but as soon as framework is used (and therefore not all modules are included) it works... so something is "clashing" (@GaryV - I assume that, so feel free to ignore my useless posts which stop others from trying out Bruceys projects). EDIT2: Ok, so I compared "ld.tmp" of both - with - or without framework. And then appended "Import XXX" for the differences. As soon as I appended "Import Brl.TGALoader", the png-images were not loadable anymore. The Error is happening somewhere in "TPixmapLoaderTGA:LoadPixmap"... I assume it has to do with the stream position not getting reset correctly - and therefore the other image loaders not reading the headers correctly... narrowing down further. bye Ron |
| ||
| Ok ... just a short note: The error is based on the changes regarding streams (large file support): So the new "fseek_" (pub.mod/stdc.mod/stdc.c) returns incorrect values. EDIT: Seems fseek_ and ftell_ both need to flush the stream first to make it work:
int fseek_( FILE* stream, BBLONG offset, int origin ) {
// flush stream when using _fileno
fflush(stream);
int f = _fileno(stream);
return (_lseeki64(f, offset, origin) >= 0) ? 0 : 1;
}
BBLONG ftell_( FILE* stream ) {
// flush stream when using _fileno
fflush(stream);
int f = _fileno(stream);
return _telli64(f);
}
EDIT2: Create a pull request for easy fix inclusion. bye Ron |
| ||
| Hmm, so it appears that _lseeki64 and friends are not buffered - unlike the ones I replaced with them (on account of not all version of Windows, apparently, supporting the buffered versions, i.e. _fseeki64 and friends)... Fun fun... |
   |