|
Post by matthew on May 22, 2012 19:26:23 GMT -5
what kinda projects are you working on nutter? I believe one of them might be music related.
|
|
|
Post by angros47 on May 23, 2012 7:58:20 GMT -5
I started porting the sprite library to linux, as an external library (to be able to use it in freebasic, too). So far, i got sprites working (even animated ones), using stb_load instead of Corona. I also made some changes: commands like SprSetAngle now requires to specify the sprite you want to set; also, LoadImageStrip now returns an image buffer pointer, instead of a texture pointer (I used the same format of FreeBasic image buffers, so when using the library in FB it's possible to convert an image buffer into a sprite, or to load an image with LoadImageStrip and then use the FB command "PUT" on it); this means that it's still possible to load sprites with the same syntax, but if you are going to load a texture to use directly in OpenGL you need to use gluBuild2DMipmaps or similar, you can't directly use the value returned from the load command. Oh, sprites by defaults have the same size of the image. Here is the source code: it's still very incomplete, and contains many unused functions (I used part of openb3d source as a "template"). The file "functions.cpp" contains implemented commands. www2.zippyshare.com/v/56282330/file.html
|
|
|
Post by matthew on May 23, 2012 11:26:52 GMT -5
Thanks for contributing angros, I've uploaded your spritelib to the Wiki.
|
|
|
Post by Tom Mulgrew on May 24, 2012 1:56:21 GMT -5
Keep meaning to chip in, then life interrupts me..
I'm quite interested in how this pans out. I'd been thinking that an Open Source project would be the ideal way for b4gl to continue given that I don't have time to push it forward on my own anymore. However contributing to an existing project is much more feasible. I have a number of half started b4gl versions around that could be canabalised for code. There's one with a wxWidgets IDE (no syntax highlighting or debugging support yet, does do tabs though) which was intended to become a fully cross platform version. There's also an old Linux one with plug-in library support.
I'm assuming the main goals are to get a basic cross-platform version up and running, then build up the different function libraries..?
|
|
|
Post by matthew on May 24, 2012 3:45:07 GMT -5
Don't worry about being interrupted by life, we're all suffering from that, what with Josh studying & me trying to find a new job.  You're correct in assuming that we're trying to develop a cross platform version. It looks like we'll be using wxWidgets & SDL as the main libraries. Our goal is a version of Basic4GL which can be built completely from Source on either Windows, Mac or Linux.
|
|
|
Post by Darkjester on May 24, 2012 14:02:37 GMT -5
Keep meaning to chip in, then life interrupts me.. I'm quite interested in how this pans out. I'd been thinking that an Open Source project would be the ideal way for b4gl to continue given that I don't have time to push it forward on my own anymore. However contributing to an existing project is much more feasible. I have a number of half started b4gl versions around that could be canabalised for code. There's one with a wxWidgets IDE (no syntax highlighting or debugging support yet, does do tabs though) which was intended to become a fully cross platform version. There's also an old Linux one with plug-in library support. I'm assuming the main goals are to get a basic cross-platform version up and running, then build up the different function libraries..? as matthew put it quite correct  , but im curious as to how one could implement syntax highlighting using your codebase, i cant seem to figure that portion out as well as how to reintegrate the standalone exe's portion of the code, i may just be overanalyzing -darkjester
|
|
|
Post by James :) (aka Madcow) on May 24, 2012 19:24:26 GMT -5
On the wxwidgets website they recomend www.scintilla.org as a syntax highlighter. For standalone executables hiw I envision this if we wanted to make it multiplatform we would have to have some template C++ code for an .exe which the IDE would use. It would send this to a compiler (the user would either install this or we could find a way to package this into the IDE) who would compile it to the target platform (initially we would only let it be compiled to the host platform, i.e macs can only generate mac executable, linux generate linux excutables and windows generate windows executables) but in time if it were possible we could put in support for cross compiling. Obviously it would also have to give the complier all the images and resources it needs to pack into the excutable to run
|
|
|
Post by UNDISCLOSED on May 24, 2012 20:40:00 GMT -5
Ah, B4gl, if it weren't for you I wouldn't know how to program... I don't think I will ever come back to B4gl, it's not really what I need any more, but I have and will still be keeping an eye on this thread, giving my opinion on things because I remember I liked this forum... That was a long long time ago, I don't even think I would even say I am still the same person any-more... For what it's worth I think that an IDE is not really that important, at the very least I think it should be separated into a separate executable, for multiple reasons, such as keeping code distinctively separate and so that using the IDE is not mandatory (I understand that a command-line interface could be built into the IDE but I think it is neater to keep them separate) I think what you guys are doing is great, hopefully the project will draw many more people into the field of programming 
|
|
|
Post by matthew on May 25, 2012 6:37:47 GMT -5
Thanks for the comments wolfman, what kind of programming are you doing nowadays?
On the subject of IDE development I suppose we could always distribute two different versions of Basic4GL, one with an IDE and a separate Command-Line version.
|
|
|
Post by Darkjester on May 25, 2012 14:45:13 GMT -5
Tom can you explain how the "standalone" portion works, as i am unable to call vm.StreamIn(stream) even though its define in TomsVM class Attachments:
|
|
|
Post by Tom Mulgrew on May 25, 2012 17:10:07 GMT -5
In the current source, the syntax highlighting code is in SourceFileFrame.cpp, method TSourceFileFrm::SourceMemoGetLineAttr, and also Basic4GLv2Main.cpp, method TBasic4GLv2MainForm::GetTextTokenStyle.
Obviously it's tailored towards the edit control that Basic4GL uses which relies on the Borland VCL, so isn't cross platform at all. But it does demonstrate the basic logic of finding the different tokens within the line of text.
In the wxWidgets version I have floating around uses the Scintilla component (they have a wrapper class to turn it into a widget). I believe it has all the functionality necessary to recreate the Basic4GL IDE (syntax highlighting, rendering a left hand side gutter for breakpoint icons). I haven't got my head around how yet, but it is possible.
|
|
|
Post by James :) (aka Madcow) on May 25, 2012 17:34:57 GMT -5
I know some people are saying a IDE isn't important, But I feel to make the compiler easier to use and quicker to test we could use an existing one temporarily. I've been thinking about using the IDE from processing 
|
|
|
Post by Tom Mulgrew on May 25, 2012 17:39:20 GMT -5
Do you have a basic overview of how the standalone exe mechanism works? In Windows it works like this: You have a "stub" .exe containing the VM (Virtual Machine) and libraries. The start-up code pulls data out of a Windows resource and streams it into the VM. This sets the VM up as if you had just compiled the program, and it can simply run. The main Basic4GL application creates the standalone exe by: Compiling the Basic4GL program Calling VM.StreamOut() (I think...) to save all its data to a block of memory. Copying the "stub" .exe Writing the streamed data into the Windows resource of the copied file. This is all done in TCreateStandaloneForm::CreateStandAlone in CreateStandalone.cpp, using BeginUpdateResource, UpdateResource and EndUpdateResource. (There's a bunch more stuff related to embedding files etc, but that's the basic idea). So the obvious issue with extending this to be cross-platform is that Windows resources are Windows specific. You'd need to find an equivalent mechanism in Linux etc for writing data into an executable file that the program can retrieve at runtime. I haven't had a chance to look at your code yet. But I thought that rather than throwing different versions of the source code around, it might be better to get things setup as a proper project hosted in source control, with a clear objective of where you want to take it. So that people can jump in and help out where they can. Although maybe you're already there..? Are you using James' git repository for this (I believe he mentioned it earlier)..? Is that somewhere it can live long term? Are you able to state what your goals are for the initial phase? From above posts I've deduced: * Cross platform (at least Windows, Linux and possibly Mac OS) * Plug-in library support * Standalone exes (or equivalent in other OSes) * Re-implement OpenGL and support functions (like image loading) * Possibly re-organise some of the libraries. Move things like Joystick and Networking into plugin libraries?? * Maybe re-implement the IDE using wxWidgets (  Not sure about this one). -Tom
|
|
|
Post by Tom Mulgrew on May 25, 2012 17:43:59 GMT -5
I know some people are saying a IDE isn't important, But I feel to make the compiler easier to use and quicker to test we could use an existing one. I've been thinking about using the IDE from processing  I'd say it depends on what the goals are for the new version. For the original, the idea was to have a friendly environment where you could type a small amount of code, click "Run" and see what it does, without having to fiddle with text editors and file system folders.
|
|
|
Post by James :) (aka Madcow) on May 25, 2012 18:25:57 GMT -5
Well if we are to keep the original design then the processing IDE would suit it as both processing and basic4GL are similar in wanting to allow you to write code very quickly
|
|