suggestions for improvement
BlitzMax Forums/BlitzMax Programming/suggestions for improvement
| ||
| This thread is a place for peope to post suggestions for making BlitzMax better. This may have been started elsewhere but a quick search did not turn anything up. It would also be nice if some official that works at Blitz Research would monitor this thread and indicate which suggestions are going to be implemented and (more importantly) how far down the road they are planned. Since I am starting this thread I will make the first suggestion. 1. Innate support for audio and video streaming. I know there are some modules that permit this but I would like to have this feature built into the basic language. A lot of my programming is multimedia related so this improvement is very important to me. I remember reading somewhere in one of the forums that this was due to the way the audio part of the language worked (I don't know if this is true though) but even if this means rewritting the entire audio part of the language I think it would be worth it. 2. Support for .mp3 audio. I know this is a copy righted format but with so much music out there in this format it is a weakness for BlitzMax to not support it. I know I could convert the .mp3 files to .ogg files (which I am currently doing) but this takes time. Alright, I've started this thread so others feel free to jump in. Jason |
| ||
| /me sitting and waiting nerds and flammers. |
| ||
| Two missing features: 1. Native printer support. 2. Form editor. (both for MaxGUI) I don't want MP3 support, and neither do you since you need to pay for a licence if your application uses it. Use variable bitrate OGG format. Smaller file size, better quality, no licencing costs. |
| ||
| I know this is a copy righted format Since you don't care about the license problems, you can easily use BASS or FMOD to play mp3 files. They both work just fine with Bmax. I don't see them implementing mp3 support with the license fees being what they are, so either use whats already out there or forget it I would say. As for what could make Bmax better, the first thing I can think of is a better 2D module (not something I need desperately myself as I have written my own, but I think its something that is generally wanted by most). |
| ||
| IDE : Code folding, icon support and better debugger Max2D : Streaming audio/video, Render-to-texture, Printer support, textured polys. There have been a number of these posts over the last few years and the lists probably identical as I can't remember any of them being implemented. Has anybody ever got a suggestion/request accepted? |
| ||
| You may find it quicker to implement said features yourself... |
| ||
| Has anybody ever got a suggestion/request accepted? Reflection, maybe? I expect someone requested that, but in real terms, I guess that wouldn't count. It wasn't implemented because people wanted it, it was implemented because Mark needed it. The only things I'd like to see are some additional language features which cannot be implemented as modules. Things like function overloading, method pointers, properties, operator overloading, and access modifiers which actually work on methods, functions and fields. Anything that can be implemented as a module might just as well be done by a third party IMO. |
| ||
| You may find it quicker to implement said features yourself... Yep and also rely on the great user community members who fill the holes. However, nothing beats an officially supported solution. |
| ||
| Minimise button on Mac. Quite a few of my suggestions and bug fixes (mainly fixes actually) have been implemented by BRL over the last 18 months so that's cool. |
| ||
| Threading support. For what might be considered a modern language, it's terribly unusual to have it not be safe to use threads. Most of the requests above could be fixed by users willing to learn how to do things themselves. May as well ask for something a little more useful and complex. |
| ||
| Quite a few of my suggestions and bug fixes (mainly fixes actually) have been implemented by BRL over the last 18 months so that's cool. That means something like 'a few of my suggestions have been implemented' doesn't it? What, other than bug fixes, did you suggest that was implemented by BRL? |
| ||
| In short, I agree with Gabe and Noel. Reflection, maybe? I expect someone requested that, but in real terms, I guess that wouldn't count. Yeah. But that was at least 2 years ago. It wasn't implemented because people wanted it, it was implemented because Mark needed it. Exactly. Hopefully Mark will need functional access modifiers and multithreading soon. However, nothing beats an officially supported solution. Really? Well I have two real world empirical examples that blatantly contradict your assumption. Support isn't really one of BRLs strengths - or maybe we just have wildly different opinions on what constitutes product support. Not that I blame them mind you. Even monolithic Microsoft can't even pull off half-decent product support, so expecting any better of a small privately owned New Zealand company is somewhat ludicrous. |
| ||
| Support isn't really one of BRLs strengths Depends on your definition of 'support'. How about... http://en.wikipedia.org/wiki/Product_support I personally think I do a pretty good job of 'providing the end-user with a resource for information regarding the product, and help if the product should malfunction'! |
| ||
| In that case we can soon expect fixes to the recent serious incompatibility issues of Max2D DX7 and B3D on NVIDIA 150+ driver series? No, BRL support is great when it comes to problems with the licenses for example, no question there. But the costumer care end has potential to be done better. For example the absence of a bug list with [confirmed][worked on][reviewed][fixed] made me think for a long time if its worth to post bugs (BM at least got cured due to the presence of SVN). But Blitz3D and BlitzPlus still suffer under that problem. Its unknown, if the current compatiblity issues and straight crash bugs in B3D are even beeing looked into for example. As I officially take care of the Realm Crafter Standard community (RC Standard bases on Blitz3D and BlitzPlus), its of higher importance to me than just "nothing different to do" and <= 4500 other licensees of RC that these bugs at least get looked into so we can release (free or not free) our MMOs for example. So I hope you understand that I do not want to rant. But I would like to see a more professional handling of bug reports. By professional I mean a more transparent one to the users (what has been fixed, what is confirmed, what is beeing worked on) instead of the "mystery guessing" that currently takes part. I would be willing to pay a yearly "subscription" for active updates and bugfixes of the given Blitz Product (or all owned products) and a more transparent product handling. |
| ||
| I think the job is pretty well done too considering the size of the company. No complaints here. |
| ||
| Three things I'd like to see added are : 1) All axis rotation of images. 2) Native Theora support with sound. 3) Build in way to add exe icons. |
| ||
| But I would like to see a more professional handling of bug reports. By professional I mean a more transparent one to the users (what has been fixed, what is confirmed, what is beeing worked on) instead of the "mystery guessing" that currently takes part. Sorry, but that ain't gonna happen. For better or worse, I *like* the current bug report system and have no intention of replacing it with anything requiring more maintenance or work on my part (although I do quite like DBPro's simple 'confirmed/solved' forum tags...). If you're unwilling to use it, then fine, but don't expect any fixes in a hurry! For me the bottom line is: I do frequently compare the support I provide with that provided by other companies for similar products, and honestly consider I do better than most. |
| ||
| Support aside, since I don't really care anymore, what about threading? |
| ||
| I would already be quite happy if [confirmed],[worked on],[reviewed] (means that the bug is checked if it is a bug or just a combination of user errors), [fixed] were used so the bug reports get a status. Nobody said that the bug report system needs to be replaced. I'm no fan of mantis or bugzilla. They are "hard" to use for common users and out of my sight a serious overkill for something like the blitz products I think. A board is a appropriate solution for it out of my view. |
| ||
| what about threading? Hmm... How about: describe your ideal threading API and I'll describe the problems! Perhaps we'll come up with something...? |
| ||
| I'm most familiar with pthreads, although I doubt anyone else probably likes that sort of system. [edit] One alternative to that would be the boost::thread library, as it was pretty nice in the short time I tried it. Since you're more familiar with internals (goes without saying..), I'll let you start off with the problems. |
| ||
| describe your ideal threading API Check out the one in Freebasic. Its equally simple and robust. http://www.freebasic.net/wiki/wikka.php?wakka=CatPgThreading |
| ||
| I personally think I do a pretty good job of 'providing the end-user with a resource for information regarding the product, and help if the product should malfunction'! Well I'm not going to get into this with you here, but you might want to check out the demo version of BlitzMAX that you can download from this site, and then get back to me on whether you honestly think version 1.12 is at all representative of BlitzMAX. How about: describe your ideal threading API and I'll describe the problems! I'll take java.lang.Thread and java.lang.Runnable for 400 Alex. Basically one is an object you extend, for any Class you want to run in a separate thread, the other (my favorite) is an Interface you implement and "load" into a newly forked thread. 3) Build in way to add exe icons. There already is. I do frequently compare the support I provide with that provided by other companies for similar products, and honestly consider I do better than most. Sure. |
| ||
| I'll take java.lang.Thread and java.lang.Runnable for 400 Alex. Basically one is an object you extend, for any Class you want to run in a separate thread, the other (my favorite) is an Interface you implement and "load" into a newly forked thread. I like the idea of providing an implementable interface for objects that will be threaded. As-is, we could do this by simply providing an extended Object type, such as ThreadedObject, that you would have to extend in order to use with threads.I'm not familiar with Java's threading API however, so I may have some misconceptions just based on that description. Shall look it up later when I'm not starving. |
| ||
| I'm not familiar with Java's threading API however, so I may have some misconceptions just based on that description. It's dead simple. You implement the Runnable Interface, give your class a run() method (ideally, if we want to avoid multiple inheritance, we could pseudo duck type any classes having a run() method to automatically be considered Runnables - since this can be determined at compile time) then you instance it with code like this:MyRunnable myObject = new MyRunnable(); Thread myThread = new Thread(myObject); myThread start() // invokes the run() method;Any potenntial concurrency issues are handled by the Monitor, which can be invoked by using wait() and notify() before and after the critical sector, or simply encasing the critical sector in a synchronized() block. |
| ||
| Ok, Warning: A lot of this rant probably suggests I'm anti-threading. I'm not. I am, however, relatively anti-'threading as it's generally known'. The main language-side problem with implementing 'normal' multi threading involves the garbage collector. Either the current reference counter would require a 'Lock' on it's increments/decrements (which would add approx 100 cycles to the current 10-ish cycles required for an inc/dec); or, the garbage collector would have to be changed entirely to something like a generational collector, which *would* suffer for collection pauses. The 'prefered usage pattern' for generational collectors does not appear to be 'game friendly' - ie: it hates lots of 'medium life' objects: It ends up having to visit *all* objects quite frequently esp. if you're creating lots of medium life things. So, either way, the same single threaded app would run slower in 'multi threaded' Max. I don't think this is something to be taken lightly, and dismissed with the argument that the benefits of multithreading would make up for it. They wont always. Not everything benefits from threading. However, that's just the language fix. In addition: Lots of stuff in modules would require synchronization primitives added to them. At the very least, BRL.Blitz would require tweaking, and probably anything that hit the OS, as different OS's have different 'rules' about threading. Win32 likes some stuff to only run in the 'main' thread, while Cocoa is 'mostly' threadsafe! As for non-OS stuff like TMap, TList, TBank, etc, either synchronization of this lot could be left up to the user, or applied by BRL over a no doubt torturous development period! One approach would be just to do the language/BRL.Blitz fix and leave everything up to the user, but the set of *useful* things that would 'just work' on all 3 platforms with this approach is likely to be pretty small. And I suspect that many languages that advertise 'multithreading support' take this approach - ie: synchronize the language core and leave it up to the user to deal with OS-specific issues. So I guess to summarize there are 3 options here for implementing normal threading: * Make the language/BRL.Blitz thread friendly. * Make the language/BRL.Blitz and OS stuff thread friendly. * Make everything thread friendly. Either way, the same single threaded program will run slower, and threading (beyond printf's on 2 threads!) is still very, very tricky to do *right*! (I think my biggest beef with 'normal threading' is this: You basically start out with a 100% unsafe system, and it's up to you to meticulously make it safe.) So that's the state of things for normal threading support. I would really like to come up with a new approach to threading that eliminates these problems and provides robust threading - and don't forget, I do get to tweak the language if necessary. One alternative is process level threading, where each 'thread' has an entirely separate memory space. This is an extremely safe way to do threading - and many of the above issues just don't exist - but with one major drawback: You can't easily 'share' objects. It's also relatively expensive in terms of OS resources. Reflection would probably make it possible to synchronize objects between processes but with some overhead. I guess providing some kind of IPC would at least be a safe, simple way to get a kind of threading happening - be a good excuse to implement QNX IPC again! Trolltech are also about to release a very interesting approach called qtconcurrent or something. This basically parallelizes things very much the same way a GPU does - ie: does the same operation multiple times. But it's done in a completely safe way, in that there are no synchronization primitives to worry about. This is where I'd be interested in looking at how the language could perhaps be changed to support threading - perhaps by marking a method as 'Parallel' which limits what it can do (eg: can't write globals - can't call non-parallel methods etc) so that it can safely run in parallel. Then, "For EachIn actors Run Update()' or something... A combination of this with process level threading to handle the 'big' jobs (eg: update/render/physics) is, to me anyway, a far more appealing and interesting way to go than normal threading! But yes, it's all pretty experimental.... |
| ||
| One approach would be just to do the language/BRL.Blitz fix and leave everything up to the user, but the set of *useful* things that would 'just work' on all 3 platforms with this approach is likely to be pretty small. And I suspect that many languages that advertise 'multithreading support' take this approach - ie: synchronize the language core and leave it up to the user to deal with OS-specific issues. This is how I would do it. I may be placing too much faith in programmers, but it's my belief that people will not automagically assume that using threading is going to benefit them. Some degree of research would have to be invested by anyone wanting to use it, obviously. I don't think there's any good way to make threading friendly to people, it's just something you have to bite the bullet on in a lot of cases.So, my ideal choice would be the first option. The second would probably be more of a bonus than anything else, and the third is going a bit far when a lot of BMax's existing modules simply wouldn't need thread-safety since I can't imagine anyone using, say, Max2D and just the regular modules to make a small game or application would be interested in using threading. It wouldn't benefit them in any way to be frank. With something like I'm doing, a full-blown engine, there can be benefits, especially for a client/server design similar to a lot of engines now (e.g., Source). Now, this: One alternative is process level threading, where each 'thread' has an entirely separate memory space. This is an extremely safe way to do threading - and many of the above issues just don't exist - but with one major drawback: You can't easily 'share' objects. It's also relatively expensive in terms of OS resources. Reflection would probably make it possible to synchronize objects between processes but with some overhead. I believe this is what Valve (Half-life guys) are using in their engine to minimize the amount of trouble encountered with threading. Somewhere, there's a bunch of slides where they go over their threading solution and from what I remember, they synchronize global data between threads by means of a queue. Before a thread uses the global data, it checks for a new version and replaces the old data with the new before going ahead and uses its own copy of the data.It will consume more memory, this goes without saying, but these days I don't think that's as much of an issue. Most machines these days should have more than enough to accommodate this solution, especially considering if you were to put this into use, it likely wouldn't be on an old P2 with 128mb of RAM (I probably have my specs for old machines mixed up- might be 64mb). In the event that someone doesn't use threading, then this wouldn't be an issue and memory usage would be relatively normal- at least within the bounds of regular indie games (since that seems to be what most people here are doing), even if it might not be as little as possible (but then if you were trying for that, you'd be using C/C++). A combination of this with process level threading to handle the 'big' jobs (eg: update/render/physics) is, to me anyway, a far more appealing and interesting way to go than normal threading! More or less my opinion on it. Using threading for small tasks, things that just wouldn't ever see a potential benefit from it, is pointless as far as I'm concerned. Sure, it's neat when you start, but that's not why you'd really use threads.I'll see if I can find Valve's slides. It had to do specifically with multi-core systems, but it's still relevant if I'm not mistaken. |
| ||
| Found it: http://www.valvesoftware.com/publications/2007/GDC2007_SourceMulticore.pdf I thought it was an interesting idea, although there's probably better solutions out there by now. |
| ||
| 1. RectsOverlap 2. CopyRect 3. ImageBuffer 4. MouseXSpeed 5. PlayMusic (midi, mp3) 6. PlayMovie 7. Rect/Oval (unfilled) 8. List.before/after (slow) 9. ^2 be optimised as a special case for ^ 10. String.copy(times) 11. Only import the functions that my code is using. |
| ||
| 1. RectsOverlap 1) Come on, you can do this yourself.2. CopyRect 3. ImageBuffer 4. MouseXSpeed 5. PlayMusic (midi, mp3) 6. PlayMovie 7. Rect/Oval (unfilled) 8. List.before/after (slow) 9. ^2 be optimised as a special case for ^ 10. String.copy(times) 11. Only import the functions that my code is using. 2) Not really feasible. 3) Pixmaps are the closest you'll get to this, stop asking. 4) Again, come on. 5) So there's a difference between music and sound? 6) Already have options for this, and if they don't meet your needs, try it yourself and see if you'd want to do it. 7) See 1 and 4. 8) No idea what you're going for here. 9) No, because ^2 is not any more a special case as any other ^n. This defies logic. 10) See 8. 11) See 2. Study compilers and linkers. |
| ||
| 11) See 2 (2: Not really feasible.). Study compilers and linkers. Really? I thought it would be as simple as, if function:helloworld is never called don't compile it.. |
| ||
| It's really not that simple. I want you to sit down and think about these situations: - What if it's only passed as a function pointer to other parts of the code? - What if code that imports this code needs it? Is a compiler supposed to know between instances of it being run whether or not a function should be excluded, especially without current knowledge of the other code? The compiler does not build the code in one run, it's run for each and every file. How do you intend to solve this such that the compiler will intelligently know what functions should be excluded for every possible situation? - If the code is from a module, how is the compiler supposed to handle this? Rebuild the module every time it needs to be used? These are only a few, but should hopefully give you an idea of why it's not as simple as predicting the runtime of an application (as if that were simple these days). |
| ||
| ah yes, i forget about modules :( |
| ||
| 1) Come on, you can do this yourself. 2) Not really feasible. 3) Pixmaps are the closest you'll get to this, stop asking. 4) Again, come on. 5) So there's a difference between music and sound? 6) Already have options for this, and if they don't meet your needs, try it yourself and see if you'd want to do it. 7) See 1 and 4. 8) No idea what you're going for here. 9) No, because ^2 is not any more a special case as any other ^n. This defies logic. 10) See 8. 11) See 2. Study compilers and linkers. 1. Blitzmax is supposedly still geared towards games and easy to use. If you don't believe this I understand your point. 5. I don't know? What does that have to do with these file formats? I agree with Jason. 6. I know. I agree with Jason. 7. This is one of the most common problems people run into then have to ask in the forums. See 1. 8. Returns the next element in the list. Is slow because it has to search the whole list. 9. Definately possible. x^2 can be converted to x*x because 2 is a constant. 10. Blitz3d string() function. 11. I was referring to built-in functions only. Just an AutoFramework command. I have taken classes on compilers. |
| ||
| 1) You're telling me that this is hard to do? Also, I do not believe it's geared towards beginners, but rather intermediate to advanced programmers. 5) Midi is an outdated format and if you want it, it's up to you since demand is simply not there. You can deal with MP3 as well, read the license. 6) Then what are you doing about it? 7) I don't know what's wrong with other people then. Maybe they're stupid? 8) Get the link and use it as an iterator. 9) I didn't say it wasn't possible, I said it was a bad idea. It making a special case of something that is not special and should not be treated as being special. 10) In that case, this is another 'it's so simple that you really should shut up and do it yourself instead of complaining about it not being there.' 11) These 'built-in' functions are all in modules. Not possible. |
| ||
| 5) There are already two fully working solutions for mp3, either BASS or FMOD and with the license issue of mp3 Bmax will never get out of the box support for that, so people might as well start using the alternatives. 6) If someone needs video playback, then take a look at mplayer, which can be embedded into your application fairly easily and it plays just about any format out there. 7) There are a few examples in the code section that does unfilled circles. And unfilled rect is 4x drawline in a function, really easy to do, not really needed as a command, there are other more complex things they should spend their time on. 10) This is again so easy to do and while I appreciate various built-it string functions, I would again prefer if they spend their time on the complex stuff, which the majority cannot do themselves. |
| ||
| 100) Guys you're dreaming.... do you really think these function will be added because your rant? 1000) If you have sh!t load of money to license MP3, just use another engine, isn't that just 10000x easier? 10000) Any threads like this just irritate Mark and co, and Blitzers here. I'm sorry to be rude BTW. |
| ||
| @About Multithreading in Bmax (from a newbee point of view about it) If the problem is 'share' all globals, tlist, tmap and so on, it could be easily to create a 'SharedGlobal, SharedList, SharedMap' objects *specifically* designed to cope with multithreading? In this case *only* a small part of BCC and some modules (if needed) must be modified/rewritten. And then multithreading will be a choice of the programmer... To come back on the thread - an official support (for all the platforms) for 'audio streaming' - some *fix* to centering windows (I need to change manually some files to do it) PS: for audio (and video) support BRL could create a 'multimedia module' (maybe with 'other' effects) and sell it, like MaxGUI - I like the idea of 'free' support for the MAIN core (and MaxGUI) but it is not written anywhere BRL can NOT sell other modules...of course just my opinion. |
| ||
| Those multimedia module would have to support audio record (voice etc.), screen recording, et . as well :) Regarding multithreading: I'd really like to have that for math operations. For the rest I don't really bother because it's a pain in the arse to get it right. I'd rather have BRL building in some way of using multithreading without knowing it ie. loading game ressources, threaded user input etc. |
| ||
| As for BMax's target audience, I actually think it's from beginner to advanced. You aren't forced to use superstrict, you aren't forced to use pointers, function pointers, types, inheritance, anything. So, if you rate yourself a beginner you can just go on without them, and code in peace. Of course, the only problem would be asking help on these forums, where most of the solutions you get are superstrict compliant and use some of the things I've mentioned. :P So, because of that, there may be a point for some of these seemingly simple enhancements, because there may really be beginners around here. Question, of course, is whether BRL should provide those enhancements or someone from the community should. |
| ||
| 10. Blitz3d string() function. Surely you can't be serious? The show stopper for your current project (as it were) is a function that takes an arbitrary string, and appends it to itself an arbitrary number of times? Astonishing. 11. I was referring to built-in functions only. Just an AutoFramework command. I have taken classes on compilers. Really? Maybe you should supplement it with classes on algorithm performance.While sure, it's theoretically possible (you could build object code for only units, and use the linker to work out all the possible states a program could be in), doing so is an NP-complete problem (and in many cases might provide sub-par performance). Sure you could do it, but whatever real or imagined benefits you think you might gain from this, is probably not worth compilation times measured in days, rather than seconds. I'd rather have BRL building in some way of using multithreading without knowing it ie. loading game ressources, threaded user input etc. With core stuff like the ability for executing code in parallel (and sharing resources between them, which is the whole point of using threading, as opposed to multiple processes), I really think there needs to be more low level access to these things. There can be high-level "helper functions" as well, but these don't necessarily have to come from BRL. Of course, the only problem would be asking help on these forums, where most of the solutions you get are superstrict compliant and use some of the things I've mentioned. Not all problems are elegantly solved using simple tools. Hell some aren't even elegantly solved with horrible and complex tools. |
| ||
| I checked out mplayer because it was mentioned on this thread and found it to be very complex. I am a beginner programmer and don't even know how to use mplayer (or fmod) with blitzmax. I am looking for something easier to use such as the build in LoudSound and PlaySound commands (I easily learned how to load and play .ogg files with the build in commands). Jason |
| ||
| I checked out mplayer because it was mentioned on this thread and found it to be very complex. I am a beginner programmer and don't even know how to use mplayer (or fmod) with blitzmax. I am looking for something easier to use such as the build in LoudSound and PlaySound commands (I easily learned how to load and play .ogg files with the build in commands). Too bad? Learning is good for you. Makes you smarter. |
| ||
| I am looking for something easier to use such as the build in LoudSound and PlaySound commands (I easily learned how to load and play .ogg files with the build in commands). Here is the problem tho'. MP3 (and its ilk) is not one of those hippie/commie free for all formats like Ogg/Vorbis. The MP3 format costs (from memory) $2500 USD per title for a game or $15.000 USD if it's an application. If you have that kind of money just burning a hole in your pocket, finding someone to create a wrapper for FMOD, Windows Media Player or whatever is going to cost you pocket change by comparison, and it's not going to be a huge problem for long.Like yoko said, if you have enough money to legally use the MP3 format in the first place, chances are better than average you're not using $100 USD development tools. |
| ||
| I think Mark's posts are the only posts that I read every word in it no matter how big it is. If this threading thing is going to delay the 3D stuff for another year then screw threading... |
| ||
| 3) Build in way to add exe icons. There already is. Really? - Where is that then FD? - I can't see anything in the IDE which allows you to pick an icon for an exe file? - unless I'm missing the obvious!. |
| ||
| Then if streaming for .mp3 is so expensive then how about built in streaming for .ogg/theora/.mpeg formats? The buildin streaming doesn't have to be specifically for .mp3. Jason |
| ||
| I think Mark's posts are the only posts that I read every word in it no matter how big it is. Undoubtedly. Where is that then FD? Incbin. Look at the MaxIDE sources for an example. I can't see anything in the IDE which allows you to pick an icon for an exe file? So much like every other IDE then? Then if streaming for .mp3 is so expensive then how about built in streaming for .ogg/theora/.mpeg formats? Sure. However to provide reliable streaming audio/video you first need reliable multi-threading. |
| ||
| Incbin. Look at the MaxIDE sources for an example. That is not a built in method. I can't see anything in the IDE which allows you to pick an icon for an exe file? So much like every other IDE then? Not really. The Delphi IDE has the option to choose an icon for your exe. It is that method I'd like to see in the max IDE. |
| ||
| I'd like to see the icon for your .exe option too. |
| ||
| I'd like to see the icon for your .exe option too. Get BLIde Plus! :D |
| ||
| That is not a built in method. What? How is Import (sorry, not incbin) not "built-in" by any stretch of the imagination? Not really. The Delphi IDE has the option to choose an icon for your exe. Eclipse doesn't, neither does VisualStudio. Neither do Borlands non-Delphi IDEs. Nor does X-Develop, InteliJ or Codewarrior. It would seem that Delphi is the exception, rather than the rule, which seems to reinforce my statement that MOST IDEs do not provide such a limited way to add resources to your binary. |
| ||
| Those who wat to do something with BMax... Get Grey Alien's Framework, not joking, not advertisement, I just think that'll help you guys out. |
| ||
| However, nothing beats an officially supported solution. Really? Well I have two real world empirical examples that blatantly contradict your assumption. Support isn't really one of BRLs strengths I would rather have a good supported solution than a good unsupported solution. I could probably provide quite a few more exceptions/examples myself. However, my comment was informal and offhand and should not be taken as 100% fact born out of statistical analysis. Personally, I don't find BRL support *that* bad. - or maybe we just have wildly different opinions on what constitutes product support. probably.... but that doesn't make you wrong. |
| ||
| I would rather have a good supported solution than a good unsupported solution. BRL is not the only company who provides support for its software products. It wasn't the degree of support offered by BRL I was trying to make a point about, just the somewhat absurd idea that BRL is the only entity to offer that degree of support.To single two members out here ziggy and Grey Alien both have very good products with good enough support. Personally, I don't find BRL support *that* bad. I didn't say it was bad. I said it wasn't one of their strengths. I then went on to compare their degree of support favorably to Microsoft. |
| ||
| Because I'm currently working on minib3dextended 0.45 I have a suggestion which I believe is useful for everybody. As a few of you know my latest version requires maxgui to compile without modifactions. What about a new compilerdirective maybe something like: ?module:scope.modulename eg: ?module:brl.maxgui 'maxgui code here ? 'other code I know this could be done by a precompiler but it would be more easy to have it natively integrated. |
| ||
| BRL is not the only company who provides support for its software products. It wasn't the degree of support offered by BRL I was trying to make a point about, just the somewhat absurd idea that BRL is the only entity to offer that degree of support. To single two members out here ziggy and Grey Alien both have very good products with good enough support. I completely agree. However, others have not continued supporting released modules through release changes (which is a pain but fair enough for 'free' code) or the authors have simply disappeared. Personally, I don't find BRL support *that* bad. I didn't say it was bad. I said it wasn't one of their strengths. I then went on to compare their degree of support favorably to Microsoft. Sorry misunderstood Support isn't really one of BRLs strengths as suggesting it was a weakness. One of the problems with forum interaction. IF BRL had implemented their version of many of the 3rd party solutions then, in my opinion, BlitzMax would be a better product (it's already very good) with a bit more confidence in continued support. ... or, at least, I would. |
| ||
| Weak references (http://en.wikipedia.org/wiki/Weak_reference) are a feature I've wanted more than once. |
| ||
| Weak refences (http://en.wikipedia.org/wiki/Weak_reference) are a feature I've wanted more than once. I hadn't heard of Weak References before but after reading about them on Wikipedia, they seem like they would be a welcome addition to BlitzMax, especially with the garbage collection problems you can easily get through accidental circular references etc. Is such a compiler feature easy to implement? |
| ||
| I didn't say it was bad. I said it wasn't one of their strengths. I then went on to compare their degree of support favorably to Microsoft. FD, what you did is called back-tracking. :) |
| ||
| The whole topic of threading is interesting and I do think it's something that really needs to be tackled in the coming year. So many more computers now are coming out with multiple cores and/or CPU's as standard and if Blitz isn't taking advantage of that increasing trend it's going to be left behind. Imagine I have a computer which has a combined CPU-core rate of 4GHz, but everything you write for it in BlitzMax only runs at half speed, and then Blitz gets a reputation for being twice as slow as other software, that's not a good thing. I think I would prefer threads over processes although I think both really should be implemented with more control possible. Naturally a process is in an isolated memory space but this of course means pieces of your software are isolated from each other and sharing is optional - and there is very little in the way of easy sharing currently available. On the other hand threads at least start out by assuming that everything is shared and then leaves it up to you to implement safety *where you need it* as an option. I think if you start out with processes and you try to turn an essentially isolation-based system into a way to share parts of software, you're going to have to be asking the programmer to deliberately define every `open door` between any two parts of their application. I think it would be far more natural and easy to simply have all the doors open right from the off and then put into place options to shield parts of the system as needed. Then because it's on an as-needed basis you aren't forced to be confined. It is more natural to start with openness and to close off the parts which are are at risk, than to start with a totally closed system and to try to open it up. Also threads are meant to be more efficient than processes with less overhead and processing requirements. Taking a step backwards and trying to make processes act like threads should seems like the wrong direction. Maybe instead of needing to implement a lock for the garbage collector you can simply implement more than one counter per object and then just add the counters together when it comes time to check them. Assign each counter to a given thread and let it modify only that counter. Then when thread A is modifying its counter and thread B comes along and modifies its counter for the same object, which who knows could make one counter be 1 and the other -1, adding them together will take care of the multiple dereferencing. Of course that would mean more memory space for keeping the counters and maybe you'd have to limit how many threads can access an object at the same time, but hey even if it could only do 2 or 4 threads that would be worth it. However you do it, I think you should start with threads which give you efficiency and flexibility and then build in `helper options` to make things safe which need to be. You could have a SuperSafe mode to be used by newbies which locks down a lot of stuff, a Safe mode for the average user, and then a Generic or Raw mode which requires the programmer to define on a more per-object or per-function type of basic which pieces of code are assigned to what threads, create their own threads, manage them, set up their own program structure, etc. If for example I know that I want to provide support for up to 2 or 4 threads - given that 2 or 4 core cpu's are popular, (and we need to support simultaneous multiprocessing too,) then I should be able to specify some kind of compiler directive to say to compile for that kind of `target` hardware and then specify which areas of code I want to assign to a given core number by default, and then have dynamic thread allocation in the language, and hey presto. The only part I think is BRL's job is making the garbage collector work efficiently and potentially safely (if desired by programmer), making sure BlitzMax's lower level stuff is internally thread safe like o/s calls etc, and then provide language/compiler features to give a nice useful flexible and powerful API to the programmer. |
| ||
| - Function folding in the standard IDE - Printer support from within MaxGUI and/or Max2D - Additional blend modes - Integrated support for application icons from within the IDE, without needing to resort to reshacker after the fact |
| ||
| Make the processes completely memory seperate and then provide the means to allow the user to tunnel data backwards and forwards between threads... via mutex, locking, semaphore... whatever... its a win-win situation for anyone with multi core... currently some people are just waisting 75% of their available CPU resources... by using BRL... |
| ||
| What? How is Import (sorry, not incbin) not "built-in" by any stretch of the imagination? You know exactly what I mean!, no in fact I'll spell it out. IMPORT to an external resource file is not a built in method to add an icon. And in case you don't understand. IMPORT does NOT add an icon to an exe. However it does allow the inclusion of an external resource file which contains an icon. I was merely asking for a built in method in the IDE which make life easier for everyone to quickly and easily add an icon to your exe, like the delphi ide. I don't care what *most* IDE's do or do not do. Why you insist on quoting and arguing the toss is beyond me, but it's all you seem to do and it's getting annoying. |
| ||
| - Multiple inheritance/interfaces - Better conditional compilation |
| ||
| I like the proposed approach with "multiple processes" instead of Threads, especially due to the pointed out problems and the fact that people surely don't want to have their performance degraded just because they do not use multiple threads :) |
| ||
| So make a threaded and a non threaded compiler and let the user choose which to compile with. Add an option to the IDE that says "Threaded?" |
| ||
| Imaginary, do you know what you're talking about? |
| ||
| However it does allow the inclusion of an external resource file which contains an icon. Yes. Because on Windows, using the PE/32 binary format, that's how you "add an icon to an executable". Why you insist on quoting and arguing the toss is beyond me, but it's all you seem to do and it's getting annoying. Don't hate the player, hate the game. |
| ||
| Qube: Some advice re: FD. He sometimes gives useful advice, if so, grab it while you can, if not just ignore, OR if you are feeling perky - poke back in the sprit of his game, but don't let the bugger get to you ;-) This works for other forum members too (mostly). I should heed my own advice more... |
| ||
| Qube, I get that smart-alec crap from a few here too. I pay them no mind tho. Just let it roll off man. I still keep helping where I can and hope for the best. |
| ||
| Yes. Because on Windows, using the PE/32 binary format, that's how you "add an icon to an executable". Yes, I know how it works in reality, it's what I currently do with my max exe's. My point being it would be nice to have a visual solution built into the IDE. poke back in the sprit of his game, but don't let the bugger get to you ;-) Nah, I never pander around peoples moods, that just builds on their bullying mentality :) |
| ||
| If I didn't already have a solution, I'd like a built-in option to select an icon too. So I think it's a good idea for everyone else. Actually it would be easier than what I'm doing anyway, so sure, add it in BRL! :-) (pretty please). Or we could just swap IDEs as has been mentioned - I might try that in Jan. Nah, I never pander around peoples moods, that just builds on their bullying mentality :) you could have a point, so maybe just ignore them then? That's my new year's resolution, just ignore the few tw*ats round here. |
| ||
| I totally agree with you GA. Right on, man! |
| ||
| I like FlameDuck. He keeps things interesting! Something I would really really like: enumerations. Please I love them and can't bare to be apart from them! |
| ||
| The thing I would like the most, is probably the simplest.. You have appDir(),appFile(),appTitle(),appArgs() and launchDir(), what about appBuild() This should be simple to implement; the complier just needs to increment a value in a control file within the application folder each time the application is built. It needs to be a text file, so that the programmer can change or Reset the version numbers as required. (But this file should not be required for the finished product) Then you can do things like debuglog( appBuild() ) |
| ||
| A simple const is surely better suited for that because not every test recompile is meant to raise the build number so you would end with many more file modifications than actual builds. |
| ||
| Thats just part of the Change process I'm using. Every build is potentially a new version, even the test ones. |
| ||
Just discovered a way to change icon using ResHacker via command line...Reshacker.exe -addoverwrite name.exe,name_output.exe,icon_name.ico,Icon,101, [the last one *damned* comma...] This is quite easy to implement in MaxIDE (I'm working on it) - just need the reshacker.exe somewhere on the HD...not a big problem I think. Of course remains the problem of the 'on window' icon - but it can be resolved via some hacking already posted. |
| ||
Multiple extends:Type Point Field X#,Y#,Z# End Type Type Angle Field Pitch#,Yaw#,Roll# End Type Type Entity Extends Point,Angle Field Name$ End Type |
| ||
| This would need additional implementations of Selection, Removal, Rename capabilities if there are colliding fields. The only language I know which is really capable and therefor shining in that sector is Eiffel, that OO wise lets every other language look like kiddie stuff, even Java and C# But what would be great would be an "extend 1 class but multiple abstract classes" capability to other languages. |
| ||
| There is a good reason most modern languages do not implement multiple inheritance. It can get out of hand really quickly and most problems it solves can also be solved by single inheritance. I have to say I'm pretty happy with the language. The tool set could use some love though. Like others have mentioned - code folding, icons, I wouldn't mind a way to add windows summary info to a file. I would love to see find and replace with a good reg exp system ala bbedit, sciTE. Compile time scripting (bash, batch etc.) would be a great bonus. |
| ||
| I want one very simple thing, which is Drag'n'Drop-able source file tabs in MaxGUI(Moving source file tabs in gui by dragging with mouse) |
| ||
| I want more beer. And a picture of mordy. |
| ||
| What about coroutines instead of actual threads? The lack of parallel execution is a big down side, but on the other hand there's no synchronization issues. |
| ||
| Well, that's not really an alternative to threading. |
| ||
| yup, time slicing is already possible if you use an event queue and event handler and most likely what many did in one or the other way already. |
| ||
| The REALbasic IDE also allows to define icons for your application (even in three different sizes). You might not need it in games, but multithreading is a MUST HAVE for server and application development. The process-based multithreading as Mark describes it would be a good solution (it probably scales better on multi-core machines anyway). I'd also think that something like Brucey's database modules should become an official part of BlitzMax. Since licensing is also an issue here, SQLite and PostgreSQL support would do. Once it is finalized, wxMax should supersede MaxGUI. It looks like wxMax is the answer to all GUI-development-related needs. Oh, and somebody should write a good book about all this. :) If somebody is willing to pay for a sabbatical year to do this, I volunteer. ;-) |
| ||
| I give my vote to enums and private fields. When I initially started working with BlitzMax, I was gobsmcked to discover that, as an OO language, it didn't support private fields. I'm not really bothered about thread tbh, but that probably down to my lack of understanding the benefits... |
| ||
| One of the main benefits would be the possibility to load data while your program runs further like there isn't anything continously going on. That allows you for example to load media on the fly instead of having to do "load pauses" or restrict the image sizes to make the load "nicely" along the regular work. |
| ||
| This should be simple to implement; the complier just needs to increment a value in a control file within the application folder each time the application is built. Use version control software. Even CVS and VSS comes with simple keyword substitution functionality.The idea that Mark should hack functionality into a language, that already exists in tools you should be using in the first place, and has no place in a language anyway, is somewhat disturbing. The lack of parallel execution is a big down side, but on the other hand there's no synchronization issues. The only reason people need multithreading is because current trends in CPU design are putting more cores (with comparatively less power) on the same die. You will have to stop writing software based on 1960's paradigms eventually, you might as well do it voluntarily. The process-based multithreading as Mark describes it Is not multi threading at all, and is already achievable. The whole point (ie. advantage) of multi threading is that the two threads share the same memory pool, and thus the same data, so you don't waste precious resources copying, maintaining and synchronizing data between "instances". While using processes eliminates the concurrent access problem, it introduces a redundant data problem instead, as there still isn't a mechanism to ensure that data is only modified at a single discrete point in time. Imagine a video game server if you will. Lets say you spawn one process/thread for each player who joins. For a process based model, this means you need to keep one copy of every object in the game in every process, and manually keep them synchronized, whenever data changes, and pray that a race condition never occurs. For a threaded model you just need one copy in memory and a mechanism (a problem clever people have figured out how to solve 100 times over - use a monitor) to prevent races and concurrent access, you do not need to keep the data synchronized, because there is no redundant data. If somebody is willing to pay for a sabbatical year to do this, I volunteer. How much? |
| ||
| Isn't there? Shared Memory actually ensures that only one instances modifies it at one time (at least on Unix, never worked with it on Windows as our computer OS courses are Unix based) |
| ||
| Isn't there? No. One of the main benefits would be the possibility to load data while your program runs further like there isn't anything continously going on. Another use for multi threading could be garbage collection, so your game doesn't visually pause while doing memory management (because it's being done in another context). |
| ||
| No what? Did you never have a teacher telling you that a single word is no full sentence or do you try to life up to your names expectation flamie? This whole discussion brought some quite good points in until you showed up again. You are worse than any manic depressive I know! That would actually badly decrease the performance instead of raise because the GC checks for "can I free" would lock the objects ... Couldn't think of a much worse idea performance wise. |
| ||
| No what? No there isn't? Did you never have a teacher telling you that a single word is no full sentence No. That would actually badly decrease the performance instead of raise because the GC checks for "can I free" would lock the objects ... Sure. If you wrote a "dumb" GC operating on a flat array. |
| ||
| I still vote Interfaces :-) |
| ||
| Going back to Garbage Collection for a second. I'm not up on all the issues with threading, but isn't it possible to embed a version of the GC with each thread? Then it only handles object references on that thread and there would be no locking issues. You'd need to have some means of moving/copying objects from one thread to another, but I would have thought that it would solve the resource locking problem. Or did I miss the point? |
| ||
| Yupp. Because an object can not leave the GC controlled space so you could not share objects between threads |
| ||
| Yupp. Because an object can not leave the GC controlled space so you could not share objects between threads I was not thinking of 'sharing' exactly, but moving. For instance, you may have a thread that loads images while the main thread does some kind of intro. Then at the end of the process, there would need be some mechanism of copying and registering some of the data into the other thread (in the process moving some information from one GC to the other). Then at termination of the worker thread the embedded GC cleans up anything that hasn't been moved. Sharing data on threads can understandably cause locking problems, but a mechanism for moving stuff from one thread to another would be ok wouldn't it? If each thread had it's own GC, couldn't entries be moved from one instance to another? Anyhow it was just an idea, not needing to hijack the 'thread' :) |
| ||
| Potentially with a smart trick |
| ||
| While sure, it's theoretically possible (you could build object code for only units, and use the linker to work out all the possible states a program could be in), doing so is an NP-complete problem (and in many cases might provide sub-par performance). Sure you could do it, but whatever real or imagined benefits you think you might gain from this, is probably not worth compilation times measured in days, rather than seconds. How about something like: If sourceCode.contains("PlaySound") Then addImport("BRL.Audio") ? I'm hoping that would increase compile time since a program with just Print "hello" currently takes 10 seconds to begin executing on my decent computer. |
| ||
| How about something like: If sourceCode.contains("PlaySound") Then addImport("BRL.Audio") ? I'm hoping that would increase compile time since a program with just Print "hello" currently takes 10 seconds to begin executing on my decent computer. Because that will (in general) increase compile times for code of any complexity, not reduce it. |
| ||
| How about something like: Well then you have to determine which PlaySound it is, because obviously you don't want to write the code to handle conditional importing. In which case, let's say two modules have a PlaySound function- which do you import? What about three? What if your code already has it implemented and this imports a module with it, but the function is not in the source code of the file you're currently compiling?If sourceCode.contains("PlaySound") Then addImport("BRL.Audio") ? I'm hoping that would increase compile time since a program with just Print "hello" currently takes 10 seconds to begin executing on my decent computer. I don't think you understand what you're requesting. It's not a simple problem that can be solved with a one line "if," it's much more complex than that. |
| ||
| I'm hoping that would increase compile time since a program with just Print "hello" currently takes 10 seconds to begin executing on my decent computer. Use quick build. It takes under a second on mine. Linking is quick. Considering we already have the Framework command, I don't really see how this feature would be a priority. Framework will always be superior. Whether or not your program loads oggs, for instance, or just wav files is determined at run time, not compile time. You know this, and can not include oggs with the framework command, but the compiler cannot. Also, with reflection everything has access to everything - again, determined at runtime. Multithreading is a much more sensible feature addition. Hard, but at least it will be useful. |
| ||
| Going back to Garbage Collection for a second. I'm not up on all the issues with threading, but isn't it possible to embed a version of the GC with each thread? Then it only handles object references on that thread and there would be no locking issues. No, I don't think this is possible. The problem is determining which thread owns the object so the GC ref-counter (or write barrier for non-ref counted GC) knows which GC 'state' to modify. There are 'ThisThread()' style API calls, but an API call per pointer write would not be practical. I'm hoping that would increase compile time since a program with just Print "hello" currently takes 10 seconds to begin executing on my decent computer. I suspect there is something badly wrong with your setup! As for stripping out unused functions, this is possible in some cases and I'll revisit it. This is really a job for ld - which does in fact have strip options - but my last attempt at using them ended in crashtasy. May be usable now in latest version of mingw/macos tools. As for multithreading in general, here's a pretty good beginners guide for game developers: http://www.gamasutra.com/features/20060906/monkkonen_01.shtml To me, the most intriguing is the 'data parallel' method as it scales very well. |
| ||
| I just wanted to add that method-pointers would really help me out. |
| ||
| > Going back to Garbage Collection for a second. I'm not up on all > the issues with threading, but isn't it possible to embed a > version of the GC with each thread? Then it only handles > object references on that thread and there would be no > locking issues. No, I don't think this is possible. The problem is determining which thread owns the object so the GC ref-counter (or write barrier for non-ref counted GC) knows which GC 'state' to modify. So you can't just keep a pointer to the GC's dataset / object (not sure if it's procedural C or CPP) in each Blitz object? That seems like a pretty easy to way to keep track of which GC owns which object. With this scenario, it should still be possible to allow threads to write to each other's objects - that will require programmer synchronization to be safe. I realize this has to be difficult, but it is worth it. Sorry to resurrect this sort of old conversation, but we really need this stuff. Even the most basic, tortuous implementation would be better than nothing. Don't try to invent something amazing, just give us threads and let us clean up the mess we make with them. |
| ||
| Well then you have to determine which PlaySound it is, because obviously you don't want to write the code to handle conditional importing. In which case, let's say two modules have a PlaySound function- which do you import? You must really hate the default IDE. It, along with most other people, doesn't care about this issue. Its quick-help selects the built-in playsound function regardless. And its a HUGE benefit for most of us! If you have edited the modules, you might need to disable this feature. And I do understand what I am requesting. It's okay to argue that this request isn't as important as some other requests, but don't just say that this request will not help at all or cannot be done. I suspect there is something badly wrong with your setup! I'm beginning to suspect that too. It's a lot faster if it isn't the first time I compile after starting up the IDE. But that is the case a lot of the time because I tend to keep opening blitzmax for quick things. |
| ||
| Don't try to invent something amazing, just give us threads and let us clean up the mess we make with them. And from the other side of the debate, on behalf of those people who are using BlitzMax for commercial development of non-threading applications, just don't add threading at all if it's going to make non-threaded applications run slower and have messy hacks in half of the modules, as Mark himself suggests above. A messy hack and clean up your own mess is the absolute last thing BlitzMax needs in my opinion. |
| ||
| It's okay to argue that this request isn't as important as some other requests, but don't just say that this request will not help at all or cannot be done. It won't help at all. Whether or not it can be done, and it can but only via cheap, hacky means, is not really an issue. It's like asking if you can cut off your toe and pickle it without bleeding to death- of course you can, but it's still stupid (although in this case, cutting off your toe is the much simpler thing to do). |
| ||
| Do we really need threading, couldn't we use a core process for data, which could then be accessed with some form of locking from other processes launched as needed, e.g. sound system, graphics system, input system, physics system, game mechanics, AI, networking? Then all we would need is a nono-core cpu to run it on! ;o) |
| ||
| hehe ... yes it would be enough as most people mainly would use it for 2 things currently highly annoying. Both are blocking IO problems: 1. TCP is worthless in BM which is meantioned to be a gaming language only as it blocks the app 2. File IO in its current state at least partially enforces a preload of all data. |
| ||
Basic threading thing for loading retines could been start to supporting threading like this:Pixmap:TPixmap=LoadPixmap:TPixmap( url:Object ) Repeat Delay 10 Until isReadyPixmap(Pixmap) This would been a fine start for supporting basic threading for some functions. I can see it might been pretty hard to implement if a full treading support would been see in BlitzMax for all objects, but I cant see all objects should need thread aware? |
   |