|
Post by Tom Mulgrew on Feb 19, 2007 5:28:31 GMT -5
Okay, Basic4GL v2.4.4 is up.
It's pretty much the same as the beta I released earlier - that is there are some new window size options. Now works for standalone exes.
Oh and there's a new Peter Wirbelauer game in the demos section too.
Enjoy.. -Tom
|
|
|
Post by James :) (aka Madcow) on Feb 19, 2007 16:25:07 GMT -5
could you make a tweak where thers a check box where when you check it alows you to copy the sound dlls to your .exes directory. the new demo game has the wrong link.
|
|
|
Post by STT on Feb 20, 2007 6:26:35 GMT -5
Nice
|
|
|
Post by Tom Mulgrew on Feb 20, 2007 18:18:36 GMT -5
could you make a tweak where thers a check box where when you check it alows you to copy the sound dlls to your .exes directory. the new demo game has the wrong link. To be honest, it's not high on my list of priorities right now. There are just more pressing things that need doing. (I fixed the link tho..) -Tom
|
|
|
Post by Nicky Peter Hollyoake on Feb 23, 2007 19:49:15 GMT -5
When you use the 'allow resizing' option theres a bug in it (for me anyways. if you run the program and start resizing the screen you have to cut it off for it to go perfect but it wont let me go full screen either (you know maximize) because problems occur trying it they away I can fix this?
|
|
|
Post by Tom Mulgrew on Feb 24, 2007 1:21:08 GMT -5
When you use the 'allow resizing' option theres a bug in it (for me anyways. if you run the program and start resizing the screen you have to cut it off for it to go perfect but it wont let me go full screen either (you know maximize) because problems occur trying it they away I can fix this? It's not really a bug.. It's more that OpenGL programs have to adjust themselves to handle window resizing. You need to put this line in your main loop: glViewport (0, 0, WindowWidth(), WindowHeight()) A good place is just before the glClear(...) call (if you're writing an OpenGL program). Or before the DrawText() call if you're writing a text or sprites program. Cheers, -Tom
|
|
|
Post by Nicky Peter Hollyoake on Feb 24, 2007 13:33:23 GMT -5
Oh right thanks.
|
|
|
Post by einlander on Feb 24, 2007 15:16:49 GMT -5
this is all nice and stuff but at this moment thw way theat everything depends on everything else eliminates anyreason i have yo use this version plus i'm still waiting for subs and functions. gosub's and compile/exicute files just dont cut it in big programs. It makes prototyping god awful. The project that i am working on i had to port to freebasicv so i could understand the code that i just wrote five minutes ago and then bring it back to basic4gl.
|
|
|
Post by Supermonkey on Feb 25, 2007 19:34:21 GMT -5
That just sounds like poor coding on your part imo.
|
|
|
Post by einlander on Feb 26, 2007 20:07:11 GMT -5
You may think so but it is not.
I manually indent all my code. I obfuscate parts of my code in order to replicate subs/functions. I export parts of code into compilefile sections when they are finnished to get them out of sight. the problem is when you have GLOBAL variable with NO RULES OF SCOPE, coding gets tidius. I just find after 250+ lines of COMMENTED CODE, i still get lost.
I have written interpiteres in basic I have written an OBJ library speccifically for basic4gl without massive problems. The problem arrises when a preson attmeps to make a game with subsytems that need to work independantly of each other and of late I am finding basic4gl wholly inadaquit for this task.
poor coding my @r$e go look at some of my code and try saying that bs again.
|
|
|
Post by davy on Feb 26, 2007 20:22:09 GMT -5
I agree that Basic4GL would be much more pleasant if it had functions.
But... Properly written code in Basic4GL can go a long way without needing functions.
If I could have my way, Basic4GL would not only have functions, but would also have objects/classes (or simply allow function definitions inside of structures!!!)
But, as far as not having functions... Assembly coders had to write like that for years (some still do) and they got along just fine!
I wouldn't be surprised if Basic4GL did eventually get functions though. Especially since it's open source now (not to mention Tom is a bright guy, he just needs more free time)
|
|
|
Post by xenovacivus on Feb 27, 2007 0:05:01 GMT -5
I think in most smaller to mid-sized programs (up to several thousand lines), scope and functions aren't nescessary. And, with the proper amount of white space, a program can be coded and read easily. In almost every program I've made I could go through and make every variable global (except in c#, cuz there are no global variables...) and the program would still run. I avoid naming two different things the same way, and usually never do even if I'm not thinking about it. Having a couple variables named the same thing leads to way more confusion. I have to admit, scope would be nice though. Sometimes I have a gosub use an iterative variable (like i or j) and call the gosub from within a for/next which uses the same variable. Obviously something bad's gonna happen. Usually the program quits with an "index out of array", but other times it just quitly passes through and makes the program do wierd things. I just have to be careful of what variables I use in my gosubs. One idea I've used is to have different "levels" of the iterative variable, like i1, i2, i3... etc. Then I'll use the i1 in the main code, i2 in gosubs called from the main code, i3 used in gosubs called from i2 gosubs, and so forth. Functions can be imitated by using pointers. I usually have an array of any one structure, then a pointer to that structure. I'll assign the pointer to whatever array element I want, then call a gosub which uses the pointer. I don't do it, but you could even have variables called "FloatReturn" or "IntReturn" if you wanted authentic return values (it's way easier just to have the gosub change values in the array pointer though...). So the code would look like this:
struc sThingy ' haha. dim part1 dim part2 endstruc
dim sThingy Thingy (10) dim sThingy &TheThingy
dim i
start:
for i = 0 to 10 &TheThingy = &Thingy (rnd () % 10) gosub doit next printr "" printr "press space to do it again!" while not ScanKeyDown (VK_SPACE) : wend : ClearKeys () cls goto start
doit: TheThingy.part1 = TheThingy.part2 TheThingy.part2 = TheThingy.part2+1 print "Part1 " + TheThingy.part1 printr ", Part2 " + TheThingy.part2 return
A couple suggestions for cleaner/more productive code: * use plenty of white space * use structures & pointers to structures whenever possible * don't comment every line... only comment when necessary * divide sections of code up with several lines of cool looking comment drawings: ex-
'XXXXXXXXXXXXXXXXXXXXX---------------------XXXXXXXXXXXXXXXXXXXXX 'XXXXXXXXXXXXXXXXXXXXX-------TheThing------XXXXXXXXXXXXXXXXXXXXX 'XXXXXXXXXXXXXXXXXXXXX---------------------XXXXXXXXXXXXXXXXXXXXX
* use variable names that make sense (don't over-abbreviate names!) * even though it's a pain, you should explain complex operations step by step. And a whole bunch of other stuff. While I'm boring you out of your minds with all this stuff, I might as well add that I think the coolest programs/games were developed using systems with limitations, but the designers did something creative to overcome the limitations and make something really cool (even if it could have easily been done using a different system). I'd definitely root for the guy sliding down the hill on a shovel or couch before the guy on a snowboard any day!
|
|
|
Post by davy on Feb 27, 2007 16:22:32 GMT -5
Wouldn't it be cool if Basic4GL had a stack? Like in assembly...
You could use something like:
push 100.01 push 11.1 gosub myAddition pop a# print a# end
myAddition: pop a# pop b# c# = a# + b# push c# return
I think it would be pretty sweet.
It roughly translates to something like:
print myAddition(100.01, 11.1)
function myAddition(a#, b#) return (a# + b#) endfunction
You could essentially replicate assembly in it, except it would be much easier than raw assembly.
Even if it had 3 stacks and the commands: pushi, popi, pushf, popf, pushs, pops for an int stack, a float stack, and a string stack. Or it could simply determine which type calls it and use the appropriate one.
Stacks would allow for dynamic and "scoped" memory.
EDIT:
Another cool feature would be vectors or dynamic arrays. Something like:
dim vector a# push_back(a#, 1.1) print a#(0) print length(a#)
Not exactly that... But something of that nature.
|
|
|
Post by xenovacivus on Feb 27, 2007 22:11:43 GMT -5
you can sortof make a dynamic array.
dim &array () dim i
alloc array, 10
for i = 0 to 10 array (i) = rnd () % 100 printr array (i) next
alloc array, 20
for i = 11 to 20 array (i) = rnd () % 100 next
for i = 0 to 20 locate 5, i print array (i) next
I'm not sure whether alloc was intended to be used on already allocated pointers, but it works. The only problem is previous data in the array is lost, so you'd have to store it in another array. The following seems to work alright-
dim &array () dim &temparray () dim size dim value dim i
size = 11 alloc array, size-1
for i = 0 to 10 array (i) = rnd () % 100 printr array (i) next
value = 10 : gosub PushBack for i = 0 to size-1 locate 5, i print array (i) next
value = 13 : gosub PushBack value = 14 : gosub PushBack value = 15 : gosub PushBack value = 16 : gosub PushBack value = 21 : gosub PushBack
for i = 0 to size-1 locate 10, i print array (i) next
end
PushBack: &temparray = &array size=size+1 alloc array, size-1 for i = 0 to size-2 array (i) = temparray (i) next array (size-1) = value return
|
|
|
Post by davy on Feb 27, 2007 23:58:33 GMT -5
Yeah... I guess that works.
Not sure how it would work speed-wise considering you have to iterate over the entire array, but if you don't need it to be fast, that would definitely work.
|
|