| Joel |
is there an agi compiler out there that supports more than 255 defines? the agi studio compiler doesn't. i'll probably go ahead and just deal with it by breaking my defines.txt into multiple files, but aside from consistency with the AGI limits, there doesn't seem to be any reason for this limit. |
| BP out of area |
Tsk... only 255 defines? Sad.... didn't Peter know about linked lists or dynamically allocating memory? I'm working on C/objective C-like compiler right now which is nearly complete, and I plan to have it supporting many machines/VMs including (of course) SCI and I guess I'll exapand it to do AGI too. It's incredibly extendable, and supports infinite defines infinitely within other defines too. So you could use defines within defines within defines etc., and you define ANY type of code, including something like "#define FOO_FUNC void foo() {bleh....}". The defines also support mutli lines like C so you just need to use a \ at the end of each line. Did I mention is also supports enums and such? The defines are just a tiny part of it. It's incredibly flexible with multiple error messages (It doesn't stop after one), warnings, etc. All the experience gathered from working on my previous compilers have come into play to make this the best one yet. I don't plan on making any more compilers as a matter of fact, but instead am making this one so flexible that I will be able to modify it for any new machine I need it for in the future so I'll never need to actually write one from scratch again (or at least not for a long time). |
| sonneveld |
agi is pretty limited.. you'll probably have to write a few workarounds for stuff. since we're bragging here.. my compiler shouldn't worry about the number of defines either. :) It uses a hash lookup tables with linked lists for collisions. One thing I've found is that while it would be easier to go ahead and write a nice c compiler for agi... the original code isn't exactly c compatible. for example #defines only work when used as variables. So first plan for me is to get a compiler that's compatible with stuff now. - Nick |
| Joel |
I can't say I know enough about Delphi to know for sure, but the odd thing is that it appears Peter did use a dynamic data structure for storing the define names (specifically, a TStringList). However, he used a 0..255 array of words for the lengths of the define names. Anyway, I was able to resolve my particular problem by separating the defines into various files (which in some ways provides a greater degree of self-documentation in my code and in others is just a nuisance). All the same, it sounds like you guys' new compilers will be something to look forward to. |
| Joel | I was just thinking about this problem again and I realize that it's a whole lot worse than an "annoying" limitation. Ultimately, putting the defines in multiple files is a temporary solution at best, and in order for it to actually be doable I would need to have way too many separate defines files. Even then, it might not be good enough, define-happy as I am. I don't like having magic constants anywhere when it comes right down to it. That means I define positions, room numbers, view numbers and all kinds of things. I need a real solution to this problem. |
| gpm |
When you say you define everything, do you mean that you are using multiple defines for the same objects? Or, are you running out of defines that can be in memory at one time? What I would consider doing in your position, is a define file for every room plus some choice global defines in a globaldefines.txt file. You are right though - it is an ugly and temporary solution at best, but at least you would have some significant control over what defines are used in each room, as opposed to just simply dumping everything into one huge defines.txt file. |
| Joel |
Basically, what I mean is that even if I were to use a single define name for every flag available in the interpreter, then I would have reached my limit for define names that the AGI Studio compiler was coded to handle (I say that because the 255 limit is hard-coded in AGI Studio; there's no reason why it should be that way). If I were then to try to say #define ego o0 then I would get an error message saying basically "too many defines". This is a significant problem because I prefer to do things such as: #include "RoomDefs.txt" // for RM_INSIDE_HOUSEinstead of writing things like this: This problem is not preventing me from doing any work on my game at the moment, because I have broken the defines down into multiple files. But it will become a problem in the future, and it would be better if a solution were already on hand once it does. |
| Joel |
to be a bit more clear -- I was already using a global "defines.txt" and defining stuff that's only applicable to a certain logic within that logic itself. I originally found the problem because I had a lot of global constants defined in my defines.txt (for example, the room numbers and some of the view numbers). I then broke down my defines so that room number constants are in a file called "Rooms.txt" and so on. That has alleviated the problem for the time being, but it is not a permanent solution. It's not so much that it's ugly (it actually adds structure to the code). It's that it simply can't continue forever. If I wind up using all the flags in the engine to store game state information, then I can't have any more defines. The only solution to this (short of a compiler modification to handle > 255 defines) is to even further break down the defines into very, very specific groupings, such as "GettingThroughTheWarehouseFlags.txt". I'd prefer to avoid going to those lengths if at all possible. |
| Brian_Provinciano | All your problems could be solved with a compiler that simply took care of variables automatically. For example, it would take the fixed variables/flags, then be left with the 21x-22x ones left, then assign all the global variables in your game to v28/v32-vWhatever, then use the rest for local variables within the logic. If you use more than 256 total, it'll just give an error that you're using too many vars. It's quite simple really. One could even modify the existing compiler to support this. Then all variables would have proper names. |
| Joel | a compiler like that would also need to have a "union"-like construct, because even some global variables are only relevant within a specific context, and you'd want to be able to re-use the space if need be. |