Hello,
Now that GLBasic with a version number 5.3xx is approaching the annual cycle of a new version, I would like to point out in advance that GLBasic is going to be slowly restructured, so that a specialization towards games and entertainment will be dropped in favour of a general purpose programming language, which would be usable even for professionals.
GLBasic will continue to be a very easy to learn, quick language and as such keep the major focus on its fast graphics and a great platform diversity. Nevertheless, a wider clientele is gatting aimed at, particularly in the field of professional application which, due to the strong relation to games, left GLBasic untouched so far.
First changes, that are already in the next updates, offer an exchange of GLBasic libraries without disclosoure of the source code, extension of GLBasic by a GUI component, database integration, scripting language support and a wider range of applications in the manual and website. There will also be a real-time mode implemented, which allows displaying 3D graphics without having to use X_OBJ ... and a stronger network support.
The planned changes will occour within the next year.
I don't want to deter anyone with this, because GLBasic will certainly not lose simplicity and scope, but will only be extended in other directions.
The exotic platforms "GP2X" and "X-box Linux" will continue to be supported, even as it is now apparent that no new devices for these platforms more can be purchased. The devices had already been sold in a significant number, so that this market should not be underestimated.
Sounds great, keep up the good work!
All sounds good to me Gernot. I don't know what dent GLBasic would make in the application market, but having those tools will be a very good thing. You've got a lot of solid competition out there, Jamagic (now RIP) excelled in its support for application development as well as games but it was unfortunately not enough to save it in its case.
I'd still like to see music in the PocketPC runtime and support for tracker music built in for multiple platforms but those are my priorities. I'd also love to see the language get more support for some OOP principles which I personally think would attract more programming types to GLBasic, but I know that is a sensitive subject. If this new direction will energise you to take GLB on then go for it :)
Your move to allow better application development is exciting news, especially if you keep cross platform compatability in the process - looking forward to the first changes.
Matthew
I think the more you can offer, the better the chances are of attracting new users. Including GUI etc. etc. within the actual main core of the program is the way to go and is a better approach than buying a plugin.
To paraphrase Baldrick from Blackadder it "Sounds like you have a cunning plan" :)
One area that always seems to have overlooked in all the modern BASICs I have tried (with the exception of VB) is the ability to make use of the printer, which is obviously something that would need incorporating into a more general language. That alone could be all you need to set you apart from the competition!
Great Idea. I think the easiest solution would be to create a temporary html file and have that printed somehow. Better ideas?
Ummhh, will we also be able to change the application icon in the editor then? Because Ressource Hacker often screws up my applications :doubt:
Further to the above post -
We need an automatic icon included for both the .EXE file and the window icon (if visible) - this should not require any INLINE commands etc, it should be an option from the menu. PlayBASIC did that nicely. Resorting to ResourceHacker is never nice.
Yes, you're right. I think I'll put some tool for that in, too.
Ooops! missed this thread...
Yes I agree it all sounds great, some sort of cross platform GUI would be nice for me.
One addition I would like to see is full in-built OpenGL command support. That is, OpenGL part of the command set, not just a library, with proper compile time syntax checking. This would allow GLBasic users to extend the 3D and move 3D engine development into the community.
Apart from that small suggestion I'm a happy man. With GLBasic in general, I find the GLBasic support reassuring Gernot, so many come and go in the game developer world, its good that GLBasic has such a constant presence. :grin:
QuoteFirst changes, that are already in the next updates, offer an exchange of GLBasic libraries without disclosoure of the source code
I really appreciate this. It is nice to be able to share your work without having to share the code =D
I hope OSX compiling will continue to be supported as new versions of OSX are released.
QuoteJamagic (now RIP)
I was so sad to see the plug pulled on Jamagic.
Great ideas, and fantastic development i might add!
Gernot, you have taken DiNgS where no man has gone before.....networked, 3d style, BASIC, into the professional world?! Who wouldof guessed? Seems like only yesterday when i suggested you added 3d, networking, etc etc :)
SINCE you are going pro with it...
1. how about increasing the data putfile files from 256 lines, to infinite lines?
2. Allowing for programmers to toggle the "{pause}" feature in the compiler options?
3. Add a new feature "On top" in the compiler options? (for making 3rd party game tools etc)
I could come up with more suggestions and ideas, but i think this is already alot for you now.
1. OPENFILE
2. AUTOPAUSE
3. *gulp* :D
Quote from: Kitty Hello on 2008-Aug-07
1. OPENFILE
2. AUTOPAUSE
3. *gulp* :D
Haha sweet, you program faster than i can think ;)
What about Z ordering sprites? I can't remember if that's in already, but could it be added if not?
Quote from: Kitty Hello on 2008-Aug-07
1. OPENFILE
2. AUTOPAUSE
3. *gulp* :D
1. done
2. done
3. done..no gulping ;)
Always on top Funktion, Code ist in UserLibs:
ALWAYSONTOP() (http://www.glbasic.com/forum/index.php?topic=2207.0)
z-order is order of drawing. There is no "sprite" in GLBasic, just "Drawing" them.
That's what I meant really. Adding a priority/order to the drawing process. Possible?
Quote from: Ian Price on 2008-Aug-10
That's what I meant really. Adding a priority/order to the drawing process. Possible?
Shouldn't this be part of the sprite manager in the game engine you write?
Someone has started a 2D Entity System in the Code snippets. That's basically what you want.
QuoteShouldn't this be part of the sprite manager in the game engine you write?
I already DO have an ordering system, I just like the simplicity of a hard-coded in the language Z-order.
Div Games Studio did it beautifully over 10 years ago and very few languages have it. It makes things a lot easier for people new to coding that want to create simple 3D effects.
I thought this was an open forum for expressing ideas. Maybe I was wrong.
I want Y ordering of sprites, am I strange? :-)
QuoteI thought this was an open forum for expressing ideas.
Indeed it is, my apologies for expressing one.
The problem is, that I don't have sprites anywhere. And if I had to store sprite position/rotation/scaling and all for Z-sorting, I'd have to implement a whole lot of new commands, as it was introduced with the EntitySystem. So, I think it would be better to write your own code (it's quite easy) and share that here :P
A sprite system in GLB would be a nice game saving device to have, but I guess there's many things you might want to be able to do with it and perhaps writing your own gives more flexibility.
Talking of ordering, if a sprite system is too much, it would be nice to have some built in methods to make writing your own even easeir. For example, I think most people use a TYPE array to store a list of sprites with DIMPUSH and DIMDEL for adding/removing items in the array and FOREACH to step through each element in the array. What we're missing is a nice easy way to sort the array in to a preferred order.
I wonder if something like the following could be added to GLB?
TYPE sprite
sprnum ; x ; y
ENDTYPE
local mySprite1 AS sprite
local mySprite2 AS sprite
local mySprite3 AS sprite
mySprite1.y = 100
mySprite2.y = 50
mySprite3.y = 200
DIMPUSH Sprites[], mySprite1
DIMPUSH Sprites[], mySprite2
DIMPUSH Sprites[], mySprite3
DIMSORT( Sprites[], Sprites[].y ) // sort Sprites[] array using Sprites[].y
By the way: just noticed OpenGL 3.0 is dead!
http://www.gamedev.net/community/forums/topic.asp?topic_id=504547 (http://www.gamedev.net/community/forums/topic.asp?topic_id=504547)
ARB has always been OpenGL's worst enemy.
Noone cares here. It's just another way of writing code, it has nothing to do with features of OpenGL. Just the API didn't change. I'm glad.
Sorting by member? Sorting is definitely something I should look for. Nice idea you have there.
Would work for types, only, but it's very usefull.
Or something like a "sort by function" like:
SORTER MySort: a AS TType, b AS TType
return a.y > b.y
ENDSORTER
DIMSORT(myarray[], MySort)
I use this for sprites, stolen from the forum somewhere
// ------------------------------------------------------------- //
// -=# QUICKSORT #=-
// ------------------------------------------------------------- //
FUNCTION quicksort_y: array[] AS NPC, low, high
LOCAL lo, hi, piv, t AS NPC
lo = low
hi = high
piv = array[high].y
WHILE TRUE
WHILE array[lo].y < piv
INC lo, 1
WEND
WHILE array[hi].y > piv
DEC hi, 1
WEND
IF lo <= hi
t = array[lo]
array[lo] = array[hi]
array[hi] = t
INC lo, 1
DEC hi, 1
ENDIF
IF lo > hi THEN BREAK
WEND
IF hi > low THEN quicksort_y(array[], low, hi)
IF lo < high THEN quicksort_y(array[], lo, high)
ENDFUNCTION // QUICKSORT
Quote from: Kitty Hello on 2008-Aug-12
Noone cares here. It's just another way of writing code, it has nothing to do with features of OpenGL. Just the API didn't change. I'm glad.
What is ironic, is the official OpenGL forums say something completely different than what is summarized on the above link. It reminds me of all of the outcry before Vista was released because OpenGL supposedly would not work on Vista. ;/ If the OpenGL community doesn't have something to gripe about, they are not happy :S
That looks good Gernot - the kind of thing I'm used to in C#.
Moru - looks like an interesting function - thanks for posting that.
Gernot, can you add "delete" to the mouse for editing in the compiler?
Would be nice to del with mouse and still retain old clipboard in "cut/copy".
And theres a line in right click menu that says "insert file into project"
it doesnt work.
Please can you make some new helpfile for inline?
Maybe you can standarize it to msdn? Or is it already?
inline is described, and the code is standard iso C++.
"Insert file to project" works, when you're editing a gbas file, which is not in the project. You can add this file to the files tab then and it will be compiled.
Deleting text with the mouse? Why not hitting "del" key?
I edit with the mouse...cut paste, find, replace,select all, toggle block comment and all the tools
...delete would just make it a lil easier.
Gernot: He means putting Delete as an option on the popup menu in the editor (when you right-click with your mouse).
The easy solution is to cut what you want to delete and just not paste it anywhere.
But he wants to be able to delete without having to destroy the paste buffer. I preffer using keyboard as much as possible though, since mouses have a tendency of destroying wrists if used too much. Get used to using keyboard for cut and paste, it's for your own good :-)
delete: delete or backspace
select text: hold shift and use arrow keys
select all: ctrl+a
cut: ctrl+x
copy: ctrl+c
paste: ctrl+v
You can put four fingers from the left hand on those buttons and have easy access to them all at once without having to ever touch the mouse. These shortcuts work in all windows programs and most linux and other OS. If those don't work you can use ctrl/shift+insert and delete to get similar effects.
I would however like some fast access to the jump-list on the right side of the editor without having to touch the mouse... any ideas?
Quote from: Moru on 2008-Aug-13
But he wants to be able to delete without having to destroy the paste buffer.
I know, was just suggesting an alternative since the feature (which is fairly standard) isn't in the IDE.
I prefer the mouse as much as possible, much easier on my bad wrists :nana:
Gernot, Can you..update font tool?
Instead of a slider bar...make an actual font size number?
This would greatly improve the ability to standarize some things.
And it would help to organize our fonts better.
I recommend making it similar to the windows paint program with a dropdown list of sizes,
Sizes ..8-48
same as you have for the font type lists.
note screenshot below
[attachment deleted by admin]
Yes, I have been missing something like that but now you can at least save the settings in the tool.
Thanks gernot for delete mouse, how about undo?
Any ideas about font tool font size list instead of slider?
Moru, how do you save settings in font tool?
File -> Save
It would be nice to drop the inline command for interfacing with a library file altogether for somthing like this...
declare function config_read cdecl alias "config_read" (byval config as config_t ptr, byval stream as FILE ptr) as integer
This is freebasic, Im not a great fan of FreeBasic but this is an area that they got right, the vast amount of DLL that work easily with that language is a testiment to that.
The problem is the data types here.
But we have a Blitz wrapper for one, and DECLARE on the other had, which is exactly what you want. Just... a bit more awkward, I agree. I don't want to change it, though. I think it would make things much more complicated just for this one issue.
Quote from: Kitty Hello on 2008-Aug-19
The problem is the data types here.
But we have a Blitz wrapper for one, and DECLARE on the other had, which is exactly what you want. Just... a bit more awkward, I agree. I don't want to change it, though. I think it would make things much more complicated just for this one issue.
Yes, I see, a big bunch of C compatible data types and structures would be needed. I will need to brush up a little on my C I think :P gah! hehe
Is there any way we will get a multi-pass compiler that can go thru all files and prepare the types from all files so they can be used in the main project file? For example I want to include the keyboard handling code wich is a separate file that contains all types of keys already defined so I can use them in the game easily. This gives an error that the type is not defined. So I have to move it out of the separate file and stick it up on top of the main file wich is just what I want to avoid by having several files. Then I can just do it all in the main code anyway and be done with it. Next time I start a project I have to go thru that code and cut/paste the routines and declarations that I always use...
Hi Moru - yes I have come up against this also. Would be nice to have a good solution to it in a future GLB build.
Can you add multiple frames to X_Obj? This would allow me to solve a FPS issue with CPRINT in 3d version.
I want to make realtime animations without having to constantly build new objects, only once in a while when a string is updated....its really slow building hundreds of vertices each frame. Or increase the speed which X_OBJADDVERTEX works ..its slow.
Not, yet. It's planned though.
Feature Request
I like the "write once, compile for all platforms" aspect of GLBasic. But we really need a native "get platform" command.
Example, I am writing an image editor. On Windows I can let the user print the image from the editor. But on Linux/OS X I can't do this because the way I print the image relies on a Windows hack. I need to be able to detect the platform the program is being run on so I know whether to enable or disable the print option.
I could just compile different versions for each OS, but that does defeat the multi-platform purpose of GLBasic IMHO. No matter how much we try, certain things we can do on one platform and can't do on another. Having a "get platform" command could make life a tad easier when trying to support multiple platforms.
Just a request, not a demand.
Did you try PLATFORMINFO$() ?
Gotcha, thank you. I really do need to update GLBasic more often :-[
how about .jpeg and gif89 support =D
I think png is the way to go.
PNG gets my vote for purely selfish reasons - it's the format I use the most by far. :)
BMp is absolutely the best.
However, you cant use glbasic to view jpg and gif...these are internet web graphics
png was used to replace gif on the internet.
but gif89 is the animated web grasphic and jpg is the low compression web graphic.
I would like to make executable tools that utilize the internet graphics using netwebget
so how about it?
Hemlos: For Windows, you could use the API to load those formats. GIF and JPG are useless for gaming due to the compression artifacts. PNG would be nice, but ONLY if the alpha channel is supported.
It is. If you want alpha channel (not just transparency), you must set ALPHAMODE -1 before using it. It's all there.
Personally, I would like to see jpg support - while you cannot use it for sprites, it is perfect for full screen backdrops. GIF does not suffer from artefacts, but, from my (limited) understanding, the discussion about animated gif support was raised with another language, but it could not be incorporated due to licensing restrictions
Quote from: PeeJay on 2008-Aug-28Personally, I would like to see jpg support - while you cannot use it for sprites, it is perfect for full screen backdrops
Keep in mind, a 24bit BMP will generally compress smaller than a JPG compressed. For distribution and even using Shoebox, the only thing JPG usually offers over BMP is artifacts. =D
The size issue is pretty much why I still use BMP instead of PNG. Well, size and speed as BMPs generally load faster.
Quote from: PeeJay on 2008-Aug-28GIF does not suffer from artefacts
GIF is a lossy format and is far worse for artifacts than JPG due to the limited bit-depth of the GIF format.
Quote from: PeeJay on 2008-Aug-28animated gif support was raised with another language, but it could not be incorporated due to licensing restrictions
MNG is the animated form of PNG. The main issue why MNG is not supported by most gaming languages is everybody uses image strips for animations. The only time I see animated sprite/image formats being used is in the point and click game makers.
A few things to set straight here:
BMP - raw data+header. Up to 32 bits (4 bytes) for one pixel.
JPG - can compress very small, but might have artefacts.
PNG - something like zipped bmp. No quality loss, great acceptance in any program, quite small, no loss
GIF - can compress with RLE (worse than zip) but is limited to 256 colors! The license thing has been dropped now.
What you might safe when using JPG is what you gain in .exe size when I include JPG support. Thus, I dropped it.
Quote from: Ocean on 2008-Aug-28GIF is lossless, i.e. no artefacts.
Yes/No. Technically (data wise) LZW is a lossless compression, but GIF is not a lossless format. With the visual quality of GIF images, the artifacts can be worse than what they are in JPG due to the limited palette. Like JPG, with GIF, you can adjust the dithering/algorithims used to keep the artifacts at a minimum.
Quoteif you have to reduce color content BEFORE saving that image as a GIF
That was my point, you pretty much have to unless you are targeting archaic or obscure platforms. Any artwork I get or textures I grab with a camera or scanner are true color ;/
QuotePNG to the rescue
Amen!
It is the 21st century. The GIF format is almost 22 years old and serves no purpose today. If you load an 8bit gif it is handled as 24/32bit (depending on your graphics card), not to mention loading slower than a 24bit BMP. There is no benefit. The only reason it is still around is because Microsoft has such trouble figuring out how to implement support for PNG transparency in IE. I hate having to use GIFs on my site because of the darn IE users.
QuoteHemlos: For Windows, you could use the API to load those formats. GIF and JPG are useless for gaming due to the compression artifacts. PNG would be nice, but ONLY if the alpha channel is supported.
If you read my request, it is due to complimenting the netwebget command, not for gaming.
And PNG is already implemented.
Regardless of artifacts and compression rates, netwebget retireves a file and saves it to the name you want.
You can use netwebget to retireve XML outputs, realtime maps, and if gif89 is implemented...then we could have animated graphics....this would be nice instead of having to layer bmp/png's
It would also be nice to be able to build a gif89 with glbasic.
About using the APi, i looked into it, and i cant figgure it out.
Quote from: Hemlos on 2008-Aug-28About using the APi, i looked into it, and i cant figgure it out.
If you look at Planet Source Code, you will find literally hundreds of examples of using the API to load GIFs.
Arg Kuron youre going to make me do it? im gonna turn it into a sharware library if i have to.
Edit:
Search plant source code: gif89 in c++: No records found matching your search.
Search plant source code: gif in c++: convert gif to bmp, and other code to breakdown the gif
but none of the 4 codes listed show how to implement them into drawing them in opengl with glbasic.
Your search criteria could be better. There are examples for using the API for loading animated GIFs and custom loaders for animated GIF.
Alternatives are read up on the format at Wotsit.org and write your own loader, or use any of the numerous third-party DLLs that will load GIFs.
This is GLBasic, what you're talking about is a bit off-base(ic), and out of my league.
I was just making another addition, suggestion, for the year ahead as the topic suggests.
The idea is to compliment the NETWEBGET command, to give NETWEBGET more power, inherently, innately, fore; GLBASIC Editor is expanding in versatility....as it has been for 8 years.
Adding the ability for glbasic to view jpg and gif, would compliment the internet functions, thus adding a whole new dimension to GLBasic's power, and a bit more net-savvy.
I was just offering some suggestions in the event that Gernot doesn't implement GIF support.
We already had the discussion about JPG-support half a year ago. Since it will make the exe-file much bigger it's a no. We don't want bigger exefiles since it's supposed to be run on small computers/PDA´s too. If you want GIF and JPG support it has to be done with external DLL´s or similar
Next version will be a big update. Due to the WIZ support there will be a new setup required. New features will include natural number (integer, no floating points) support. This is very convenient for GP2X/WIZ programming, since they don't have an Floating Point Unit. Thus, the speedup will be quite immense when you use them carefully. You will be able to mix strings/naturals and floats, as you expect.
So, in order to prepare this, you can use the postfix "_N" e.g. and replace that with "#" later.
I might have to change the READLONG and other functions. No big deal, though.
Is there going to be full 3D support for WIZ, since it does have proper hardware acceleration?
when there's a driver, yes. Of course.
Cool beans :)
Quote from: Kitty Hello on 2008-Sep-03
Next version will be a big update. Due to the WIZ support there will be a new setup required. New features will include natural number (integer, no floating points) support. This is very convenient for GP2X/WIZ programming, since they don't have an Floating Point Unit. Thus, the speedup will be quite immense when you use them carefully. You will be able to mix strings/naturals and floats, as you expect.
So, in order to prepare this, you can use the postfix "_N" e.g. and replace that with "#" later.
I might have to change the READLONG and other functions. No big deal, though.
Hehe, this will suit me, I've always found that using floats in situation that require integers, rather disconcerting! :P
This is thread has been moderated, and off topic messages have been deleted.
Re: GLBasic, 2008/2009 plans
That is the topic, this thread is designated for GLBASIC future planning.
This thread has been moderated for GLBASIC planning only.
Please dont spam this thread with anything, other than GLBASIC ideas for 2008/2009 plans.
Any Flaming and/or off-topic posts in this thread will be moderated/deleted. :offtopic:
Stick to the topic.
------------------------------------------------------------------------------------------
Re: GLBasic, Pläne 2008/2009
Das ist das Thema, diesem Thread ist für GLBasic Zukunft planen.
Zu dieser Diskussion wurde moderiert für GLBasic Planung nur.
Bitte keine Spam diesem Thread etwas mit, außer GLBasic Ideen für 2008/2009 geplant.
Jede Flaming und / oder Off-Topic Beiträge in diesem Thread wird moderiert / gelöscht.
Stick zum Thema.
---------------------------------------------------------------------------------------------
これはスレッド管理され、メッセージのトピックとオフもできます。
再： GLBasic 、 2008/2009 の計画
のトピックでは、このスレッドが指定さ GLBasic 将来計画です。
このスレッドを減速され GLBasic 計画のみです。
このスレッドをマークしないでください何でも、 2008/2009 以外のアイデアを GLBasic 計画です。
任意のフレーミングおよび/またはオフされるトピックの投稿はこちらのスレッドを管理/削除されます。
に固執するのトピックを表示します。
*edit* Apologies. I logged into my other account to delete it since I never use it anymore. I was logged into this account at the same time and in the same browser and it got deleted when I deleted the other one.
idea: an option in the editor to preset a default font image.
If im not mistaking we were able to change the root directory smalfont.bmp.
This would be obsolete now because, Dings font creator makes png files.
Maybe add it to the editor outfit?
Next version will try to load both: smalfont.bmp and smalfont.png automatically.
Quote from: Kitty Hello on 2008-Oct-02
Next version will try to load both: smalfont.bmp and smalfont.png automatically.
:good:
Couple questions please?
Do you make all those fonts by hand, Or is the dings creator, building them?
Is there a way to add fonts without manipulating an image in a paint editor?
Edit: Hmm im checking that hangul thing.
The font creator, yes.
Idea: translate GETPIXEL() to a rgb value
what type of value is it reporting atm?
I always thought GETPIXEL returned the RGB values? That's how I use it so far at least.
Quote
Idea: translate GETPIXEL() to a rgb value
I've wrote this function for translate rgb value into Red,Green,Blue.
// ------------------------------------------------------------- //
// -=# F_rgb #=-
//
// ------------------------------------------------------------- //
FUNCTION F_rgb: cRGB, BYREF wR, BYREF wG, BYREF wB
wR = bAND(cRGB,255)
wG = INTEGER(bAND(cRGB,65280)/ 0x100)
wB = INTEGER(bAND(cRGB,16711680)/0x10000)
ENDFUNCTION // F_rgb
Neurox
playmusic should be able to handle midi files.
Can you mabe post a midi file that you can't play? All midifiles I can find plays just fine on my computer.
The helpfile says:
QuoteLOADSOUND
Loads the wav file file$ (PCM-wav format only) to be used with the ID num#.
PLAYMUSIC
Plays a music file in the background. All music-formats with installed codecs are supported. (midi, wav, mp3...)
Try Playmusic, is that fast enough for soundeffects when the file is cashed?
Hi Gernot,
is possible to have in new GLBasic version a command
similar to PLAY (QBasic style http://www.petesqbsite.com/sections/tutorials/tuts/sounds.htm) ?
Bye bye,
Neurox
It plays with PLAYMUSIC, just as he said. I don't see anyone saying that playsound would work?
Some of those things never made it into the current GLBasic; maybe next year eh? :P