Ah, ok.

From what I've seen of SMFL, it seems very comparable (but quite different in use) to SDL. But I suppose I don't have that much experience with SMFL.

There's also SDL 2.0, which is supposed to be finally out of beta before the year is done.

I've had a quick look at the source.

To get it to compile on Linux, you must change all the

Code: (C) [Select]

#include <SDL/sdl.h>
/*and*/
#include <SDL/sdl_image.h>

to

Code: (C) [Select]

#include <SDL/SDL.h>
/*and*/
#include <SDL/SDL_image.h>

I'm not sure if that works on OS X, but it is necessary on Linux. And obviously I had to hack up the sconstruct file.

For what it's worth, though, it seems to very almost compile for me using V8 3.16 as well (I need to perform the arduous task of compiling v8 3.18 to properly try (as you might expect, it really won't work without it unless I make fairly major modifications to the source).

I'm glad to see the source though. It may be a nice primer to getting TS up to snuff with newer V8.

Of possible relevance to this project is my recent Sphere web utilities project, which while being strictly Web JS for now is of similar format loading mindset. I have windowstyle, font, and basic spriteset loading, if there's something you (casiotone) would like to streamline (either streamline mine or streamline yours)

So it took me a while but I picked up my progress of moving this to SFML and it's now at this point with no more memory corruption.

I'm surprised you got surfaces working in such a short time in SFML. Which leads me to my next statement: I guess we have two sfml based Sphere engines. Yours may already be cross platform too!

It probably at least compiles fine on Linux. I could give it a try, I now have a newer V8 built to try it with.

Also, very interesting how the engines have turned out so far. SDL2+V8, SMFL+V8, SMFL+Jurassic. An interesting opportunity to see SDL vs. SMFL and V8 vs. Jurassic in action.

It probably at least compiles fine on Linux. I could give it a try, I now have a newer V8 built to try it with.

I've still got a lot of stuff to clean up so the git repository hasn't been updated yet. But it should compile easily!

I'm surprised you got surfaces working in such a short time in SFML. Which leads me to my next statement: I guess we have two sfml based Sphere engines. Yours may already be cross platform too!

I've unfortunately only got loading surfaces, blitting them, and drawing rectangles to surfaces implemented, so you're far far ahead of me! I imagine the more complicated surface features will be more of a problem. At the moment I've done it by storing an SFML sprite along with some information like current blend mode. Drawing on surfaces converts the sprite's texture to a render texture and back again so it's not very fast. I'm not sure what the best way to handle them is really.

I've been slowing hand-rolling my own surface functions as I see them. Check out the code (in C#) here:
https://github.com/Radnen/sphere-sfml/blob/master/Engine/Engine/Objects/SurfaceInstance.cs

I had so wanted to use a render texture, but when it came to the other stuff I was at a loss on how to do it with render textures alone. This method is the slowest and fastest. Fast since the conversion from surface to image is nothing if you script your JS right (do all of the surface methods outside of a major game loop), then it draws no faster than an image object. Otherwise since the hardware isn't being used, it's only as fast as C# pushing the pixel data which is a tad slower than C++, and constant conversions can be a problem if you modify the surface within a major game loop.

I was impressed since tung's startup game had a triangle that rotated with a line that zig-zagged through it. But I guess to get it to work without issues you had to modify his startup game to get it to show on screen... Otherwise surface.line would'be thrown an exception. Unless you just have stubs for them. His game also uses a surface in a major game loop.

I was impressed since tung's startup game had a triangle that rotated with a line that zig-zagged through it. But I guess to get it to work without issues you had to modify his startup game to get it to show on screen... Otherwise surface.line would'be thrown an exception. Unless you just have stubs for them. His game also uses a surface in a major game loop.

I'm not sure if I have a different version or something but what I have, the triangle is just a simple Triangle call to draw on screen.

It now gets to this point, and unfortunately then it crashes again. Progress!

I'm not sure if I have a different version or something but what I have, the triangle is just a simple Triangle call to draw on screen.

Well, I remember he made a compatibility version that probably removed that surface so it would work faster in the then dx8 and GL drivers.

I'm not sure if I have a different version or something but what I have, the triangle is just a simple Triangle call to draw on screen.

Well, I remember he made a compatibility version that probably removed that surface so it would work faster in the then dx8 and GL drivers.

It used to draw gradient rectangles to the screen, but the last version just loads a pre-generated image, with the generating code commented out.

Code: [Select]

/*	GradientRectangle(0, 0, SCREEN_WIDTH, SCREEN_HEIGHT, COL_LIGHT_GREY, COL_DARK_GREY, COL_BLACK, COL_DARK_GREY);
	var temp_back = GrabSurface(0, 0, SCREEN_WIDTH, SCREEN_HEIGHT);
*/	
	// DEBUG
/*	temp_back.save("bgi_" + SCREEN_WIDTH + "_" + SCREEN_HEIGHT + ".png");
	Abort("bgi_" + SCREEN_WIDTH + "_" + SCREEN_HEIGHT + ".png");
*/	

Code: [Select]

function PreRenderBackground ()
{
/*	// Draw the main background
	GradientRectangle(0, 0, SCREEN_WIDTH, SCREEN_HEIGHT, COL_LIGHT_GREY, COL_DARK_GREY, COL_BLACK, COL_DARK_GREY);
	
	// Draw the top bars
	GradientRectangle(0, 0, SCREEN_WIDTH, mainFont.getHeight(), COL_LIGHT_GREY, COL_LIGHT_GREY, COL_DARK_GREY, COL_DARK_GREY);
	GradientRectangle(0, mainFont.getHeight(), SCREEN_WIDTH, mainFont.getHeight(), COL_LIGHT_GREY, COL_LIGHT_GREY, COL_DARK_GREY, COL_DARK_GREY);
	
	// Clock space
	Rectangle(SCREEN_WIDTH - mainFont.getStringWidth(" 00:00:00"), 0, mainFont.getStringWidth(" 00:00:00"), mainFont.getHeight(), CreateColor(0, 0, 0, 32));
	
	// Draw the Sphere icon box
	GradientRectangle(0, 0, sphereIcon.width, sphereIcon.height, COL_LIGHT_GREY, COL_LIGHT_GREY, COL_DARK_GREY, COL_DARK_GREY);
	
	// Draw the bottom bar
	Rectangle(0, SCREEN_HEIGHT - mainFont.getHeight(), SCREEN_WIDTH, mainFont.getHeight(), CreateColor(0, 0, 0, 128));
	
	// Store it and clear it
	background = GrabSurface(0, 0, SCREEN_WIDTH, SCREEN_HEIGHT);
	Rectangle(0, 0, SCREEN_WIDTH, SCREEN_HEIGHT, COL_BLACK);
*/	
	// DEBUG
/*	background.save("bg_" + SCREEN_WIDTH + "_" + SCREEN_HEIGHT + ".png");
	Abort("bg_" + SCREEN_WIDTH + "_" + SCREEN_HEIGHT + ".png");
*/	
	
	// Load the appropriate background instead
	background = LoadSurface("bg_" + SCREEN_WIDTH + "_" + SCREEN_HEIGHT + ".png");
	
	return;
}

I guess I remembered wrong then!

It now gets to this point, and unfortunately then it crashes again. Progress!

Is it crashing during a windowstyle blit? Others have mentioned having issues with that during their engine developments as well.

Also @all, with regards to the "how" of all this recent Sphere engine development, keep in mind that there are different methodologies happening here; yes, there are two projects using SFML but one is in C++ using V8 and trying to offload as much as possible to JavaScript (code which would actually benefit a web-based Sphere engine immensely) and the other is in C# using Jurassic and trying to build as much directly into the source as possible.

I'm just glad Sphere engine development is progressing on (almost ) all fronts.

It now gets to this point, and unfortunately then it crashes again. Progress!

Is it crashing during a windowstyle blit? Others have mentioned having issues with that during their engine developments as well.

Nah, it's another memory corruption issue... I love C++