Skip to main content

News

Topic: Yet another sphere engine (Read 8028 times) previous topic - next topic

  • N E O
  • [*][*][*][*][*]
  • Administrator
  • Senior Administrator
Re: Yet another sphere engine
Reply #15
Ah, ok.

Re: Yet another sphere engine
Reply #16
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.

Re: Yet another sphere engine
Reply #17
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.

  • N E O
  • [*][*][*][*][*]
  • Administrator
  • Senior Administrator
Re: Yet another sphere engine
Reply #18
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) :)

Re: Yet another sphere engine
Reply #19
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.


  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Yet another sphere engine
Reply #20
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!
  • Last Edit: July 22, 2013, 12:07:09 am by Radnen
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

Re: Yet another sphere engine
Reply #21
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.
  • Last Edit: July 21, 2013, 10:37:43 pm by Flying Jester

Re: Yet another sphere engine
Reply #22

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!

Quote from: Radnen
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.
  • Last Edit: July 22, 2013, 04:14:56 am by casiotone

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Yet another sphere engine
Reply #23
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.
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

Re: Yet another sphere engine
Reply #24

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!



  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Yet another sphere engine
Reply #25

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.
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

Re: Yet another sphere engine
Reply #26


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;
}

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Yet another sphere engine
Reply #27
I guess I remembered wrong then! :P
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

  • N E O
  • [*][*][*][*][*]
  • Administrator
  • Senior Administrator
Re: Yet another sphere engine
Reply #28

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. :)

Re: Yet another sphere engine
Reply #29


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++