Pete's QBASIC Site

You know what would get me to use the latest versions? If y'all would STOP BREAKING WORKING CODE. Of course, that requires a plan ahead of time, which the FB team doesn't really seem to have. Until that happens, there's absolutely no reason to keep updating, changing code, updating, changing code, etc. especially when you're in the middle of a major production. If it ain't broke, don't fix it. So, for my only current FB project, Two Lords, I've stuck with FB 0.14 because it's the only version that will compile the game without major source changes. Furthermore, there's simply no REASON to update; the code generation is great, the EXE is small, and the program works as expected.

There was absolutely nothing wrong with FB the way it was before 0.16/0.17. And furthermore...I've said it countless times but I'll say it again here...trying to bring the existing codebase to the point of a gcc frontend is a waste of time and effort. It needs to be designed to be a gcc frontend from the very beginning. Otherwise, you are investing at least 4X as much time trying to finagle your emitter to output code that gcc is happy with.

coderJeff wrote:Serious question: if users are still using versions <= 0.16, what would it take to get them to try newer versions?

I think it's a backwards compatibility issue. People don't want to have to edit or add more lines of code to get their programs to work with a new version, when they work fine with the older version.

If upgrading to the next FB version were completely seamless, people would have no reason not to upgrade.

I started a website where i ported old classics (from 70's and 80's) for FreeBasic. I think there were like nearly 30 games allready ported when .17 or .16 (cant remember anymore) was released and only 3 of those ported games did work anymore. All the rest did need at least minor changes to work again.
Really frustrating to fix them with a knowledge that in next version, there might come same problems again.

I was pissed off but its now forgotten. As i told i am fine with latest versions but fact is that there is no point to start anything bigger project just because fear of yet more changes is too big.

I dont create nothing fancy or big with FB. It is a toy for me with what i get some fun at evenings. How ever, peoples who have created hundreds if not even thousands lines of code might get upset of all those changes and move away from FB.

That was the problem I was facing...reworking my 7500+ lines of code to work with the latest version. It simply wasn't worth it.

The latest versions of FB have a "-lang deprecated" switch that is supposed to allow older FB sources to compile. I can't guarantee that this will work for you especially coming up from 0.14. Nobody really uses it so not sure the exact state it is in. However, the FB manual has been updated with all the known differences.

I have put the question to the other FB developers if we should rename "-lang deprecated" and make it a supported dialect. A kind of half-way point between the "-lang qb" dialect with all its quirks and the strict OOP enabled "-lang fb" dialect.

Nodtveidt, what would you think about offering some feedback on where "Two Lords" is failing to compile with latest fb version, or maybe privately sharing the source to help serve as a litmus test for what changes (compiler and two loards) need be done? Maybe it's easier than you think, or worse than we think, whichever. coder@execulink.com if you wish to discuss.

I would love to see -lang depreciated changed to something like an extended qb dialect. Allowing pointers and 32bit stuff etc., but more procedural than oop. I'm just a hobbiest programmer, and don't really have any use for oop (I definitely don't have a coder's mentality) which is the main reason I haven't switched to a newer version. There just hasn't been any reason for me to.

SMC did brought up a good point.

I'm just a hobbiest programmer, and don't really have any use for oop

coderJeff: I'll bug you at some point this weekend when I get some free time.

Nodtveidt, that's cool.

As for making "-lang deprecated" a supported dialect, there's not much enthusiasm for it from the other FB developers but they are not flat-out saying no either. I don't want to create any false hopes by promising something that can't be delivered, but I think we are all kind of interested to see where this might go. It would likely be just one or two team members supporting it over the long term.

If it all works out, the end result would be a dialect representative of fbc-0.15/16 (somewhere around there, maybe no threading also). Ported C headers, pointers, extra data types, etc, should work, and no possibility for OOP, classes, namespaces, ever.

maybe someone can write a program or something which can automatically update the older version programs to latest one (i don't know whether this is possible or not...) and update it too alongwith newer Fb versions..

coderJeff wrote:Nodtveidt, that's cool.

As for making "-lang deprecated" a supported dialect, there's not much enthusiasm for it from the other FB developers but they are not flat-out saying no either. I don't want to create any false hopes by promising something that can't be delivered, but I think we are all kind of interested to see where this might go. It would likely be just one or two team members supporting it over the long term.

If it all works out, the end result would be a dialect representative of fbc-0.15/16 (somewhere around there, maybe no threading also). Ported C headers, pointers, extra data types, etc, should work, and no possibility for OOP, classes, namespaces, ever.

That's cool. Really most of the work seems like it's already done. It wouldn't be like anyone is having to work from scratch like they are with the oop stuff. I think the biggest reason no one makes more use of the -lang depreciated mode is that it's been mentioned a number of times on forums and in documentation that you all intend dump it in future releases.

coderJeff: I sent you an email with the list of errors and warnings. It seems that the vast majority of the problems come from Lithium's original raycaster source, some of which were very easy to fix. A small amount of errors came from the bass.bi that's included in the latest FB, it breaks the sound in the game because the BASS API changed since then, and the machine-translated header drops a couple of necessary constants (death to SWIG). The code that I wrote passes without a hitch. But without lang deprecated, the compiler chokes on its own vomit, even on my code (3434 errors). I reckon most of these come from the foolish idea of removing support for '$include. Changing this to #include reduces the number of errors to 729. It would literally take days to rewrite the code to fix all 729 of these errors...hence the lack of desire to move on to the latest build of FB.

It appears that aside from the implicit variable allocation issue, lang deprecated does its job as-is. Just fix the variable allocation issue and all should be golden.

I kinda sympathize with you Nek. Luckily, when FB 0.17 was released, my problems were mostly related to not declaring my variables and using variable suffixes (which I think was a rather nice way for shorthand variable declaration).

Still, I felt it was a necessary step to update my code, to keep myself in the loop. In other words, to be able to share my code, as well as to use other people's current FB code. Not to mention that ?lang qb is not the way to go if you want to use certain libraries.

Of course, all this was done with faith that no new compatibility breakages with the old code will occur.

Nodtveidt, thanks for the email. That's the first big test of -lang deprecated I have seen for while. I think we can make some progress from that.

Lachie touches on a good point regarding backwards compatibility with libraries: breaks in binary compatibility cannot be undone. burger2227 makes mention/jokes of it, but there were some real problems spanning several versions with how the fb-rtlib was initialized, DLLs, function signatures, name mangling, linker scripts, debugging suppport, etc, that needed to be fixed. We will do our best with respect to source compatibility, but if needed binary compatibility could change again in future. Just something to keep in mind when using FB user libraries that haven't been rebuilt for a while.

Most of the warnings seem to be suffix issues from Lithium's code. It looks like many of them can be autoreplaced. However, I did run into this issue occasionally:

Two Lords.bas(3879) warning 12(0): Implicit variable allocation, SC_RIGHTBRACKET

which is complete bunk.

By the way, does anyone happen to know Plasma's real name? All I could find is the name "Jon Petrosky". Anyone know if this is is right?

Bunk?

And what do you mean by occasionally?

Regarding that error, try to replace SC_RIGHTBRACKET with FB.SC_RIGHTBRACKET.

According to emails (and his email address) I got from Plasma, his name should be Jon Petrosky.

Bunk is a fancy way of saying bullshit.

And by "occasionally", I mean the error turned up a few times in the error listing; not very often, but...occasionally.

I'll do what you suggest to see if it fixes the error.

yes, i got that error occassionally when using to compile my code using FBIde and just adding a line fixed that,
i added
at the top of my code

If he's using -lang depreciated he shouldn't have to worry about name spaces.

Well, with lang deprecated, the only errors that turn up are related to the broken bass header, the undeclared variables, and the implicit conversions. The laundry list of errors comes up when I try to compile in normal FB mode. I'm considering updating the source completely, but this won't happen until the game engine is at 100% completion. Furthermore, the code has seen an additional 300+ lines over the last couple of days, and I was sure to keep the new code compatible with normal FB mode.