Sill, Visualizing
Shaltif // 06:13How about something a little different here... The following images were made using Sill, my own 'Game Making' development engine. The purpose of this test program was to visualize audio data in realtime (similar to any mediaplayer visualizer). Clicking on any of the images will show an enlarged version.
Originally, this was made in order to test Sill's 'surface' support (actually, it's drawing directly to a texture). I have run this program at 1920x1080 at 60fps with only a 20% cpu hit (the visual is vector based, so it automatically changed to fit the size of the rendering area). On the most intense scenes, the program was rendering over 5000 lines to the screen per frame*.
You can find more general information about Sill at my website:
shaltif.comFor more information on this visualizer (along with a youtube video showcasing the test program), check out the following blog post:
Shaltif's Visualizer Blog PostFor those who are keeping general tabs on Sill's development, I have most of the basics ironed out now when it comes to game creation (comparable to Game Maker's abilities). Still have a few missing features (notably, audio and network support) but at my current pace of development, I should have no problem hitting my Q3 beta release deadline. I'm already creating basic games for alpha testing Sill's features.
Until we meet again,
~Brandon
*at 1080p, as the amount of required lines for rendering is dependent on the resolution for this program.
Re: Sill, Visualizing
HiVE // 14:11Very impressive. I think I want to switch IDE...
Re: Sill, Visualizing
Matt Thorson // 04:44Looks amazing man. I'm really excited to give this Sill thing a go. You know where to find me when you need beta testers :)
Re: Sill, Visualizing
Shaltif // 06:07Thanks for the compliments ^_^. I'll make sure to send out the appropriate reminders when I'm ready for that phase in development.
I just wanted to update on something I just got working today.
Originally, Sill worked just like Game Maker when it came to Game Speed vs FPS (in that, the game runs as fast as whatever frame rate you set). The downside in this setup is that if a computer can't hit the frame rate, the entire game goes slow, rather then just the rendering portion.
As of now, Sill has been officially changed to an independent FPS vs constant Game Speed.
Imagine that your game speed is set at 60 steps per second, this means if you set an object to move right at 5 (pixels per step), in a second it will travel 300 pixels to the right. Now imagine that the game renders an fps independent of this, be it 10fps or 1500fps, that object still only moves 300 pixels to the right after 1 second. This means the following:
1. You can have the render rate the same as a user's vsync, (for example, to avoid tearing) without interfering with your game speed.
2. If a user can't hit your game speed, it doesn't mean the entire game slows down, they just miss a few frames while your game keeps running at it's intended speed (within reason, obviously if they get below a certain threshold (currently 10% of the set game speed), everything will start to slow, but rendering goes 'slower' first). In Game Maker, if the computer can only hit 25 fps, your game speed is 25 steps a second.
3. You can have your game speed much lower then the intended FPS. This means that your game can run at 60fps without forcing all your objects to move at 60 steps per second. Thus, a move to save processing.
For the Sill programmer, it's mostly transparent. You just set the game speed, similar to Game Maker, and everything else is handled automatically.
There is only one major difference.
Unlike in Game Maker, where an instance's Draw Event fires once (times views) per step, in Sill, each instance's draw event fires off once (times views) per frame. This means any code in an instance's draw event may execute at any speed outside the 'game speed' (be it 10 times a second or 1500 times a second). For this reason, it does put a little more 'draw management' on the programmer to make sure only code to display stuff is in the draw event, while all other game processing is done in the other events. IE, setting a relative x and y position for an instance in the draw event would be a bad idea...of course, now thinking about it, anyone who has used GM's view system has already run into this pitfall.
I've also found out that making this change has made fraps recording so much smoother...
..And I better conclude this before I ramble on too much. Thanks again everyone for all the compliments. I really do appreciate the motivation to complete this ambitious project.
I found forcing myself to constantly update a blog is a great motivator to work on a project, I recommend others try it for their own development (even if no-one reads it, you still indirectly end up creating a progress log to look back on).
~Brandon
Re: Sill, Visualizing
HiVE // 12:03Yeah, the first thing I did when I wrote my own rendering stuff was to break the FPS <=> room_speed link. There's significant gain performance-wise too, since you can slow down the rendering speed in order to speed up the running speed and so on... and I certainly need every last bit I can squeeze out. :/
Regarding objects, are they defined as normal C++ objects or in some IR/scripting-ish language? I imagine there's a C++ master object you've written with appropriate 'events' to override and stick code in like GM... and if you're not limited to using such objects in-game it opens up possibilities for linking up with non-game things like data structures and 'proper' controller objects which GM is pretty poor currently... is Sill rendering-only or do you aim to provide all the same encapsulated masked collision-checking, creation/destruction, memory management etc. functions? Do users have to manually load and unload graphical/sound resources or are they done behind the scenes like GM? Or both? That would be sweet...
End questions. I'll let you answer a couple now. :P
Re: Sill, Visualizing
Shaltif // 18:05Lots of questions...let me get a soda here quick and have a sit down ;P
//...
Regarding objects, are they defined as normal C++ objects or in some IR/scripting-ish language?
Alright, to answer the first question. I have tried to program Sill using just C (there is a little C++ tidbits that I wish to iron out, but mostly the C syntax is used), this is for easier portability among compilers and because I know C way better then C++. I aim to keep almost everything 'function based' for simplicity and ease of use (thus, there are very few 'custom' datatypes and structures to work with). This means I have avoided using C++ objects/classes, etc, and mainly use internal structures for storing information.
Sill, as of right now, is a Dynamic Link Library that is called via the various functions. This means the host programming language could theoretically be anything (even Game Maker, if someone makes the appropriate wrapper, could use it).
I imagine there's a C++ master object you've written with appropriate 'events' to override and stick code in like GM...
Not really an object, but more of an 'update' function that is called in a loop. There are two ways it can be used, 'locked' and 'unlocked'. In lock mode, if you do:
sill_system_update(1);
The function will not return until a user wishes to quit.
In unlock mode:
while (sill_system_update(0)) {
//anything else we wish to run
}
The function will return after every draw frame. The function returns a 0 when the user wishes to quit.
Below I have an example showcasing a basic setup.
is Sill rendering-only or do you aim to provide all the same encapsulated masked collision-checking, creation/destruction, memory management etc. functions?
Sill 'can' be render-only, but it doesn't have to be. I'm aiming to make an 'all-in-one' 2D tool or engine that a programmer can use. So yes, I have everything you have said above already included. But you could in theory use only part of Sill if your application only needed the audio engine, the event system, collision detection or the render capabilities, for example.
Do users have to manually load and unload graphical/sound resources or are they done behind the scenes like GM?
Currently, this is the case. All resources are stored externally and need to be loaded in using the various function calls. This is the simplest approach, as I will look into more advanced setups down the line. I'm also debating making my own GUI editor similar to Game Maker (which would allow for making a custom syntax parser and include custom resource storage capabilities that are better suited for Sill development), but this isn't the priority. (note, in all cases the resulting game code would be compiled down, so I plan no interpreter design)
Here is a basic example of how a Sill program operates. Take note that all of this is still subject to change, so make sure to put in your two cents ;)
(I used quotes here to 'color' the comments for easier reading)
#include "sill.h"
int main()
{
//SILL_REAL are number values, currently set as 'double' type
SILL_REAL success; //technically, I could just use bool here
SILL_REAL version; //will store the version number
sill_system_version(&version); //recall the version number stored in the Sill DLL
if (version != SILL_VERSION) { //SILL_VERSION is a constant defined in the Sill header
return 0; //So if the header doesn't match the DLL, we bail
}
//This MUST be called before any other function
success = sill_system_create();
if (!success) {
return 0; //Failed to create the system
}
//now technically, at this point, you can use Sill
//Input, Events, Collision detection, etc
//This allows you to use Sill with a 3rd party render, if you wished.
//You can also setup advanced window/rendering properties at this point
success = sill_window_create(640,480,0,"Window Caption");
if (!success) {
sill_system_destroy();
return 0; //Since we couldn't create a display window, we bail
}
//Now we got a window, the fun begins.
//Here is where you generally declare objects, load in resources, etc
//However, technically you can do this anytime during the life of the program
while (sill_system_update(0)) { //This function returns 0 when the user wishes to quit
//The update function is where all the magic happens
//It regulates all the events, all collision, input, etc and so forth
//Also, if a Sill window is in use, it will regulate frame rate and game speed
//You technically don't need to put anything in this while loop
//As all the code was defined in your objects/instances at some point
//You can use this to draw 'overlay' on your game, as this is considered part of the draw event
//For example, this will draw on top of view scope, allowing a user to make an overlaying GUI
}
//At this point, the user has decided to quit
sill_system_destroy(); //clears all memory and the window
return 0;
}
Now that's a basic setup, but I want to answer more directly with how you setup an object. So let me make an example object here:
(Take note, all Sill functions return successful (1) or failed (0).)
SILL_RESOURCE objTest, insTest;
sill_object_create(&objTest); //If this function returns 0, it failed to make the object
sill_object_event_assign(objTest,SILL_EVENT_CREATE,0,objTest_event_create_function);
sill_object_event_assign(objTest,SILL_EVENT_STEP_END,0,objTest_event_step_end_function);
sill_object_event_assign(objTest,SILL_EVENT_DRAW,0,objTest_event_draw_function);
sill_instance_create(&insTest,objTest,0,0); //Create an instance of said object, at position 0,0
Now the '_function' parts probably seem a bit confusing. These are essentially function pointers to the names of functions you have created somewhere else in the project. Lets assume I made these following functions:
SILL_REAL objTest_event_create_function(SILL_RESOURCE self, SILL_RESOURCE object_index, SILL_REAL ignored)
{
//The parameters for this function are filled in by Sill when this event/function is called
//The first parameter is always the instance ID this event is taking place in
//The 2nd is the object_index. For collision events, this is the ID of the instance you are colliding with
//In this create event, the third argument is just 0
//In events like the draw_event, alarm_event or user_event, this is the view number, alarm number or event number
sill_instance_set_position(self,100,200);
//Right now Sill is all function based
//I plan to add a pointer like setup so you can do things similar to GM style
//*x = 100; *y = 200; //Which would auto point to this instances x and y position
return 0;
}
SILL_REAL objTest_event_step_end_function(SILL_RESOURCE self, SILL_RESOURCE object_index, SILL_REAL ignored)
{
SILL_REAL x, y;
sill_instance_get_position(&x,&y,self);
//do some manipulation
//...
sill_instance_set_position(self,x,y);
return 0;
}
SILL_REAL objTest_event_draw_function(SILL_RESOURCE self, SILL_RESOURCE object_index, SILL_REAL view)
{
SILL_REAL x, y;
sill_instance_get_position(&x,&y,self);
sill_draw_line(0,0,x,y);
return 0;
}
So now we got an object that will draw a line from 0,0 to whatever the position the instance is at. You can also store custom 'instance scope' variables in events which can be recalled from other events. I'm still working on the full syntax for this, thus I'm not displaying it currently. Once I get a pointer setup in place, it should make things even easier between events.
Take note, the above code could be used to compile the program on multiple platforms, which is another major goal for Sill.
~Brandon
Re: Sill, Visualizing
HiVE // 00:28Reminds me a lot of Pug Fugly's script-based objects in GM. And yes, portability is a definite plus. So... what plans for a GM->Sill conversion tool? I'm so lazy. :P
Re: Sill, Visualizing
ChevyRay // 01:35So... what plans for a GM->Sill conversion tool? I'm so lazy. :P
Haha, awesome.
Reminds me a lot of Pug Fugly's script-based objects in GM.
Ever since I learned that, I've been programming my games in this method too.
By the way, this is looking fantastic, Shaltif.
Take note, the above code could be used to compile the program on multiple platforms, which is another major goal for Sill.
It's probably good that you're designing this with multi-platform intention from the very start; this excites me. It's unfortunate that some of the most accessible game dev tools (GM, Construct) aren't multi-platform yet.
Re: Sill, Visualizing
Shaltif // 17:08Reminds me a lot of Pug Fugly's script-based objects in GM. And yes, portability is a definite plus. So... what plans for a GM->Sill conversion tool? I'm so lazy. :P
Haha, don't expect one ;) I've seen first hand the negative publicity that similar projects (G-Java) have run into with such conversion support, nor do I want people to think Sill is just 'another Game Maker' port like G-Flash, G-Java, etc. Although it does share some similar design choices, I want Sill to be it's own creation...That's one of the many reasons I'm holding off on making a 'Sill Editor' like Game Maker has, cause then I know people will start comparing the two.
It's probably good that you're designing this with multi-platform intention from the very start; this excites me. It's unfortunate that some of the most accessible game dev tools (GM, Construct) aren't multi-platform yet.
That's because it slows down progress to make an application multi-platform, nor does it allow you to rely on any system specific support (such as the WinAPI, in this case). Before I even started writing any code, it took me at least a month of research to decide what tools I would require to make Sill multi-platform (and how to use these tools). OpenGL was a given for graphic rendering, but it took awhile before I found SDL (which takes care of a lot of the system specific environment handling that needs to be done for each platform; such as window management, input handling, audio playback, and even has it's own video rendering support).
Eventually I may replace SDL with my own systems for better performance down the line (which will require me to maintain multiple builds of Sill), but for now it's a quick solution to a glaring multi-platform issue.
Just note here, the other platforms I plan to support (GNU/Linux and Mac OS X) won't be available until quite some time after the Win32/64 ports are finalized (2010). So for those hoping to be making stuff outside Windows using Sill this summer, sorry to disappoint ;P
~Brandon
Re: Sill, Visualizing
Grashaboras // 20:41This stuff is pretty ace, loving that square visualization on the right
Pages: 1
[1]
Comments
