About the FreeBASIC v0.17b release.
The v0.17b final release is almost the same as the May 1, 2007 intermediate release except the following:
- Compiler source frozen at April 14, 2007.
- Headers (./inc directory ) frozen at May 1, 2007.
- GFX/RTLIB source frozen at May 9 2007.
Yes, it does have bugs. At least some of them are known and the details can be found on the bug tracker on sourceforge.
DOS Package:
- the dos version was compiled for i386 processor.
- the release package probably contains extra files that do not need to be there. You may notice a hefty increase in package size. Opinions on which files should or should not be included are welcome.
- has the 2.17 version binutils.
Windows Package:
- best effort was made to include the relevent .dll.a files
- you still need to get actual needed .dll files elsewhere.
- the previous curl.bi header ( prior to may 1 2007 ) was included as I found the 7.16.2 of libcurl to be a little buggy. Take special care to use the appropriate header/.dll version if using curl. (esp. the fbdoc, which uses curl)
Linux Package:
- I built the linux version on slackware 10.1 with binutils-2.17. If this package does not work for you, please let us know why. It might be necessary to have one of the other devs rebuild it on their machine with different options, and re-upload to sourceforge. But hopefully not.
Sources:
- Sources are available on sourceforge in a packaged ZIP and include ready made Makefiles file DOS and Windows.
Compiling:
- At least version 0.16 + 0.17-July-2007 is needed to compile the 0.17-final sources.
- the 0.17 packages should contain the extra libraries needed to build the compiler, what previously had to be obtained seperately.
To the Daily CVS builders:
- We will leave it up to you as to which version of the compiler you want to use to build the CVS version. There's probably not much difference from this 0.17-final version and what you are already using.
Enjoy!
Any other questions, please ask.
Jeff
About the FreeBASIC v0.17b release.
Indeed that's a good plan as it makes an on-going test if the compiler can compile itself. Only drawback is if a new feature is added and it creeps into usage in the compiler sources, that doesn't get detected until trying to compile from some older, typically a packaged, version of the compiler.
But nevermind that... Due to you guys generously providing the daily builds, the 0.17-final release is just a check-point, since I think many users have already "upgraded" from your download pages. Which is great since we don't get hammered with new complaints all at once.
But nevermind that... Due to you guys generously providing the daily builds, the 0.17-final release is just a check-point, since I think many users have already "upgraded" from your download pages. Which is great since we don't get hammered with new complaints all at once.
Quick note: the keyboard scancodes in fbgfx.bi no longer work for my program (in version 0.17b) when I try to call them within a sub, so for now I'm still using the old version of that file, renamed fbgfx016.bi.
I suspect this is because the new version uses "enum" to define the scancode constants; apparently, enum variables are not defined globally. You're probably already aware of this, but I thought it should be noted in case anyone else runs into the same issue I had.
I suspect this is because the new version uses "enum" to define the scancode constants; apparently, enum variables are not defined globally. You're probably already aware of this, but I thought it should be noted in case anyone else runs into the same issue I had.
Thanks to everyone that has been testing the fbc-0.17 packages and reporting problems, missing files, etc. It has been almost a year since the last release, and putting out this release has been ( is a ) learning experience. Your continued feed-back will help make the next release better. Thank-you.
And then another time, and compare if the last two are equal. This can catch some problems with e.g. uninitialised variables early.1000101 wrote:For building the Win32 build I use the build it's building.
That is, I build from CVS using the previous build, then rebuild with that build.
Besides, _always_ start this cycle with the last release compiler, and provide version specific ifdefs to work around versioning problems
This creates a chain of versions that can compile eachother.
This also limits the number of variants to support:
- the last release compiler
- the exact current compiler.
IOW compiler from last week doesn't need to compile todays, as long todays and the last release does.
At least this is how FPC does it for over a decade now. (tracing back to 0.1 in 1994-95)
Btw, congrats with the 0.17b release. The feature list looks like it is a impressive leap forward.
Any resolution reported by your VESA VBE (or emulation thereof) should work, assuming you have enough video RAM. Check the list returned by Screenlist on your machine.thriller wrote:does vesa support 1280x800?
I have a question regarding the usage of OpenGL and Texture in version 17b the non CVS version. While I already know that you can't do that in the CVS version. In the fbgfx and Nehe17 example there still seems to be a memory leak.. It probably has to do with createtex.bi.. which is the file that I have been using since version 16.
I was wondering if anyone has an alternative solution with loading textures in OpenGL.
I was wondering if anyone has an alternative solution with loading textures in OpenGL.