|
Socoder -> On Topic -> SuperTurtle as a community project |
|
| Wed, 02 Jun 2010, 21:50 | |
|
mindstorm8191 |
See, I have this project idea I've had for quite a while now, which I call SuperTurtle. The idea is that its a script-driven image editor. It will allow you to write a script to build an image, and then go in and edit it like any other image editor, and switch back and forth between script editing and hand editing. Instead of using an undo log, you can edit portions of the script to allow you to step back through the image's construction process. The only trouble is, I haven't determined which language to use to write this. I'm most used to Blitz3D, and it has decent image editing tools already available, but using it for scripting may not be ideal. I would also like to consider opening this up as a community project, since I don't have too much time of my own to build a project like this. And besides, I wouldn't be the only one to benefit from this project. The way I see it, I have a good idea of how I want an image of mine to look, but have no idea how to make it using regular image editors. I would imagine other people get stuck on that as well. Would anyone be interested in working on this project, as a community? -=-=- Vesuvius web game 
|
| Thu, 03 Jun 2010, 04:13 | |
|
bram32 |
You could look at GameScript, which is a scripting language for using in Blitz3D. I have used it in the past, and I found it quite good: https://www.alsbonsai.com/john/GameScript1.zip
|
| Thu, 03 Jun 2010, 04:34 | |
Jayenkai
|
I would suggest that BlitzMax would be able to parse the script at a much better rate, but... Then.. Does that really matter? I mean, at the end of the day, it's a script, and it's just going to run at whatever rate it runs. Having it be "Super-fast" isn't really TOO much of an issue, is it? *shrugs* Blitz3d is a bit slower, BlitzMax has buffer issues to contend with, and I'm sure there's a multitude of other issues in other languages. If you're most comfortable with Blitz3D, then just use that. If the community spirit feels it needs anything faster, then they can do that themselves!! -=-=- ''Load, Next List!''
|
| Thu, 03 Jun 2010, 05:53 | |
|
bram32 |
BMax could be much easier, with it's rotation and scaling commands. I have a bmax port of gamescript, if you need it.
|
| Thu, 03 Jun 2010, 06:06 | |
JL235
|
This is in regards to building your own scripting language. After googling I can only find one parser generator for Blitz Max, and it doesn't look as mature as existing alternatives for other languages. For this reason alone I would not recommend using BMax. It also doesn't look like there are any for Blitz 3D. |
| Thu, 03 Jun 2010, 06:23 | |
|
Jayenkai
|
I think he'd probably be writing one. Chances are, any decent gaming script language wouldn't be prepared for complex art based methodology. -=-=- ''Load, Next List!''
|
| Thu, 03 Jun 2010, 08:56 | |
|
JL235
|
That is what I am referring too. The best way to build a language is to use a parser generator (or compiler compiler as they are also known). It describes the language that you are building and generates the code needed for that parser. i.e. it writes the code to build the parser for you. These tools are used to build pretty much every mainstream language and other types of parsers (like for XML). |
| Thu, 03 Jun 2010, 09:48 | |
|
mindstorm8191 |
Well the trouble I see with using Blitz3D is that not everyone has the language, and if new people want to start working on it they'd have to buy Blitz3D. I'd like to find an alternative free language. I would also imagine that an issue with the program as a whole would be the regular work needed to build the images as the user works on it. Say they wanted to work on a very early section of a complex image build, it would take quite a bit of work to get to the final image again. It would be nice to use a language that supports multiple processes, or at least multiple threads... I could, alternatively, rig up a system to build the image gradually, so the application portion can continue operating. Having 3D capabilities of Blitz3D may come in handy for SuperTurtle down the line, though. Do you all still think I should use Blitz3D? -=-=- Vesuvius web game
|
| Thu, 03 Jun 2010, 10:02 | |
|
Jayenkai
|
I'm not sure threading would help, though, would it? I mean, you can't simultaneously work on any other step of the process, because each step must wait for the previous step before it can do it's thing. I think..?! hmm.. I do like the idea of being able to do 3D things to an image, though. Perhaps Freebasic, or any other free alternatives could help? I'd be wary to suggest C, this early, though, without first experimenting with all the different libraries and things. If you get the groundwork started quickly, you can try and decide what else could achieve it later, and port everything over. Right now it's all about getting it off the ground, and figuring out how it'll all fit together.. Rather than making it the best that it could possibly be, you've got to work out the script language, and figure out the best way to connect the elements, things like that.. So.. Yeah, again, I'd just stick to the language you're comfortable with, until you're ready to bump it up. (or, again, be lazy and let others do the hard work!!) -=-=- ''Load, Next List!''
|
| Thu, 03 Jun 2010, 11:52 | |
Scherererer
|
Use Yacc and Lex, they're pretty much the standard for code generators for parsers. It basically does all the work for you and creates a C parser.
-=-=- YouTube Twitter Computer Science Series: Logic (pt1) (part 2) (part 3) 2's Complement Mathematics: Basic Differential Calculus
|
| Thu, 03 Jun 2010, 15:59 | |
HoboBen
|
GIMP does this to some extent with Python. Mostly people just use existing scripts to perform a certain effect rather than the scripts being the main tool, but you could experiment with it. (Filters > Python-Fu > Console) Also, SVG graphics are just XML and you can edit those by hand - combining a WYSIWYG editor with the XML in a separate pane might be one approach. -=-=- blog | work | code | more code |
| Thu, 03 Jun 2010, 16:25 | |
Mog
|
I have a license for BriskVM, which does scripting for Blitzmax / B3D as well as interfacing. It's a bit wonky but it's useful once you look past it's strange behavior. Check it out at koriolis-fx.com @Bram, Mostly... Thanks for sharing GameScript, it seems cool but I've only played with it since today (first i've heard of it, in honesty!) - it seems straight-forward but is there a way for scripts to access variables outside of their runtime scope, or is everything locked inside of it's own little space for every script you invoke? Would be cool if scripts could access variables within the initial runtime, as well as variables spawned inside other scripts - would be useful for making small modular plugins to help build the sections of an image and pass them into other "threads", but from what i've seen (very limited, remember!) - I couldn't achieve this  -=-=- I am Busy Mongoose - My Website Dev PC: AMD 8150-FX, 16gb Ram, GeForce GTX 680 2gb Current Project: Pyroxene
|
| Fri, 04 Jun 2010, 02:30 | |
|
bram32 |
I have also a license for BriskVM. Did you download any of the recent versions? The last update I downloaded was pretty good. It solved all strange things I encountered before that. About GameScript, It's been a while since I used it, and I was only using the bmax port I made. I can't really remember how everything works in detail, but found it easy to extend once I read into the code. It has a 'Global' keyword, if that is what you mean?
|
| Fri, 04 Jun 2010, 04:44 | |
|
Mog
|
In gamescript, with Global- Say you have script 1 and script 2, and in script 1 you define 'foo' as global -- from my prodding, script 2 was unable to access or even acknowledge that 'foo' even existed in script 1. Now, take that into main program runtime- Do you remember how you would expose foo if you defined it not within the scripts, but the program itself so it could be accessed by the scripting engine? As for BriskVM, The later updates really made it come around to something useful, When i first had it- it was kind of glitchy and not worth much at all, like the infinite thread hang bug as well as some wonky behavior - Sorry for kind of derailing the topic, but i'm taking interest in scripting languages myself again. I like Brisk, and think it could achieve what mindstorm is saying, but it's not free :/ -=-=- I am Busy Mongoose - My Website Dev PC: AMD 8150-FX, 16gb Ram, GeForce GTX 680 2gb Current Project: Pyroxene
|
| Fri, 04 Jun 2010, 15:23 | |
|
bram32 |
Well, there would be a number of approaches for that. In the VM.bb file, at line 195, there is a part that says: thread\Variable[code] = var. This is where a (new) thread variable is assigned. If you replace it by your own, existing instance of GSV_Var, which is shared across different threads, they would be sharing this variable. It is then needed to know the index 'code' of these variables. You can force that by declaring such a variable at the start of your scripts. It is a bit hackish to do it like that, but I don't think there is any 'official' method to do that.
|
| Fri, 04 Jun 2010, 20:03 | |
|
mindstorm8191 |
Well back to the subject of SuperTurtle, perhaps you all could help me with its construction. See, I've tried building portions of SuperTurtle before, usually working on the image manipulation functions. The real trouble I'm having is between making functions simple, or complex. I've tried to make multiple options on the functions, but then things get more complicated when trying to add new features. Do you think you all could help me figure out the best way to approach this? I'm also unsure of how many features to offer. I'd like to basically handle as much as possible. But then, perhaps I could have alot of features managed by script-side code, though doing this may make things slower. I think these sort of problems is why I want to open it to the community; so I can get help on deciding high-level aspects of it all. -=-=- Vesuvius web game
|
| Sat, 05 Jun 2010, 13:51 | |
|
bram32 |
I'm not sure if it will work as a community project. Usually, community projects need to have a very committed group working on it. For myself, although I like the idea, I have too much other stuff to work on. But I do like the idea, from an experimental kind of view, and I do like to think along. I would suggest writing a program that creates images from script first, and then create a graphical editor that adds parts to this script. Biggest problem I could see is to make the program fast enough. Each time you change something, the entire program would need to be reparsed and re-executed. So I would suggest cutting the program in smaller parts, and save an image that is the result of that part. If a piece of code is altered, then only the surrounding part, and all follow-up parts needs to be reparsed.
|
| Sat, 05 Jun 2010, 15:08 | |
|
Jayenkai
|
Best way, in my opinion, would be to start with a little script, build something small to read+execute it, and then we'll see what we can come up with from there using that style of script. ... Without completely fudging the style of script you've created, and turning it into something completely different. In my eyes, your script is pretty much the base of your entire plan, so lets not break the rules of your script. That's the essential part, and must remain as you've defined it. Other than that, we can all help speed it up, and add extra effects that the script can use. No need for any GUI just yet. Make it script->pic, and we'll build the interface as we go. -=-=- ''Load, Next List!''
|
| Mon, 07 Jun 2010, 08:11 | |
|
mindstorm8191 |
Well, I hope to make the script as simple as possible, while still allowing a lot of control over the management of the image. Functions will be a regular tool for its users, these functions taking a wide range of variables. These functions also need to return a wide range of objects, such as whole images, point series, and color sets, and even custom data objects. Hmm, let me try my hand at a sample script This should give you a blurred star stort-of effect. How does that look to you all? -=-=- Vesuvius web game
|
| Mon, 07 Jun 2010, 08:52 | |
|
Jayenkai
|
Nice. Where you've put "Blurimage", consider having "ImageEffect(img,effectname,strength)" where the effect can be defined elsewhere, be it this-script, alternate-script, or in-engine. -=-=- ''Load, Next List!''
|
| Mon, 07 Jun 2010, 09:02 | |
|
JL235
|
I don't see anything in your example language that I can't already get in pretty much any other language. For example why should I use your SuperTurtle rather then say Ruby+ImageMagick? If you want to build a scripting language specifically for processing images then I'd aim to make a specialist DSL rather then a standard interpreted language + image process library. That already exists. As for the project itself I'd recommend breaking this up into two projects. First as an image library for the language where you will be building the interpreter. For this I'd recommend looking at existing image processing libraries. Why re-invent the wheel when you can just use someone elses? Then I'd build the scripting language seperately. About the functions you show, how would the blur work? Motion or guassian, and what size and angle? I also personally would like to be able to map functions to the pixels of an image. Something like: If you make the apply functions read only, i.e. they can only set pixels to the image by returning them, it would be trivial to parallelize the apply function and to make it atomic. |
| Mon, 07 Jun 2010, 14:18 | |
|
mindstorm8191 |
JL, I understand your point, however the other half of this project is a full-featured image editor. Instead of locking you into using just the script, or just the by-hand editor, I hope to allow the user to use both interchangeably. All the by-hand operations will generate code (of some form) in the script. The user will also be able to step through the image-build process, and edit the image by hand in an earlier step. For example, suppose you were creating a wallpaper full of scissor images, all copies of the same image. You could possibly build your scissors image using by-hand tools, and some scripting afterwards to dock it up. You then use only scripting features to finish off the wallpaper. But suppose you wanted to change how your scissors looked? You could simply go to the top of your image script, edit in some changes, and the rest of your script would use that instead. Jay, thanks for the suggestion, but I think other formats would allow more flexibility, especially with more effect input variables. Another alternative would be something like image.blur(variables). -=-=- Vesuvius web game
|
|
|
| |||
|
| ||||