Skip to main content ↑ ↓
Topic: TurboSphere (Read 2437122 times) previous topic - next topic
0 Members and 4 Guests are viewing this topic.

Re: TurboSphere

Reply #120 –
TurboSphere 0.2.4 has been released!

Now with hardware accelerated graphics and V8 3.17. I'll go and update the wiki page I made for the API in a bit, there's a lot of new stuff, but the included test game shows off a lot of it.

I've also been working on fixing up the scons file to make it build from source easily on computers that are not my laptop. Using the exact github source, it very almost builds perfectly on my Arch machine and my Debian machine. I'll update the source again soon to make it work more easily.

Re: TurboSphere

Reply #121 –
Tried to run it, got this output (had to run it from PowerShell just to get the output as the console window closed immediately when run from Explorer):

Code: [Select]
Fixed plugins: 1
Fixed plugins as recorded: 1
Opening Game.
Opening SGM file startup/game.sgm
Opening main script.
The main script is startup/scripts/Jest_Main.js
Opening script startup/scripts/Jest_Main.js
Getting number of plugins.
Getting number of plugins.
Plugin graphicSDL_GL.dll is open.
[SDL_GL] Video mode setup succeeded.
[SDL_GL] Error: GL_EXT_pixel_buffer_object is not present.

Re: TurboSphere

Reply #122 –
What is your graphics card?

I can remove that check and it will run fine (for now). I'm planning another release pretty soon, I guess one more thing to change.

Re: TurboSphere

Reply #123 –
It's a G3 Core i7, so Intel HD Graphics 4000 I believe.  I've played Team Fortress 2 and Portal 2 on this machine at 1080p and it doesn't lag at all, so quite jarring for a 2D engine like TurboSphere to fail entirely.

Re: TurboSphere

Reply #124 –
Well...I've not tested on anything but NVidia cards (that's all I have unless I go all the way back to AGP cards), and from what I hear Intel HD doesn't have great OpenGL support, so it could possibly be missing that extension. I sort of doubt that, though, it might just be that the driver won't allow it to be accessed from the compatibility OpenGL context that SDL opens.

I'm guessing that TF2 and Portal 2 have code paths that don't require certain features when they can't be used. I haven't done that yet, and so if you don't have an extension TS needs (and it doesn't need any of them yet--and likely won't for quite some time), then it will just tell you so and quit. I put that check in because I'm using that extension in the unfinished map engine (perhaps I won't now, or at least include a safe setup for when it doesn't exist), and I forgot I left the check in the graphics plugin.

Re: TurboSphere

Reply #125 –
Lord English: Are you running on Win8 or Win7? The drivers for Win8 may not work, for Win7 do you have the latest 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: TurboSphere

Reply #126 –
Windows 8.  Seems odd that the Win8 drivers would be worse than the Win7 ones, though...

Re: TurboSphere

Reply #127 –
FYI: The new release is not working on my machine, too. ( win8 ) I got the same output.

Re: TurboSphere

Reply #128 –
The default program works in Win7, but when I have it load my Radlib library (that I fitted to work with TS) it crashes with a segmentation fault error. It was in the middle of requiring scripts. There were like 51 scripts it was trying to load.
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: TurboSphere

Reply #129 –
Most likely it wasn't the number of scripts. It might have been some glitch with RequireScript, though. But I would bet it was some engine function that is not working right.

I might add that GetSystemWindowStyle causes crashes on Windows (but not Linux). I know what's wrong with it.

Re: TurboSphere

Reply #130 –
I can't run in on my Windows 7 computer. I get the same output as Lord English.

This isn't a particularly new/good computer though (2009), and it has an integrated Intel GPU with somewhat poor drivers, so that may be the reason.

Re: TurboSphere

Reply #131 –
Not that I think this will have a huge impact, but getting the newest drivers (and actual Intel ones, not the ones packaged with Windows) might make it work.

But it's possible that that GPU does not have the GL extension GL_EXT_pixel_buffer_object. In which case TurboSphere 0.2.4 will always refuse to work with it.

Re: TurboSphere

Reply #132 –
Windows Update always gets the real Intel drivers automatically for me (annoying tray icon and all), so that's not the issue.  Of course, that may not be the latest version all the time, so I'd have to look into that...  I find it hard to believe the GPU wouldn't support it at all.  Integrated or not, the i7's GPU isn't a slouch by any means--the Windows benchmark gives it a 6.8 for gaming graphics!

Re: TurboSphere

Reply #133 –
It is probably then an issue with intel on board GPUs? I have the same setup too...

Re: TurboSphere

Reply #134 –
I wouldn't really call it an 'Issue', though. I could also search for the ARB version of that extensions (which operates a little differently, but produces the same results), but we don't need that extension for anything that is happening in TurboSphere right now. I'm in a place with terrible Internet, but I'll put up a new and improved version of TurboSphere soon (this new one doesn't use immediate mode, although is really identical in performance). The new release will also include a more fleshed out plugin loading system that will be much more configurable (which is not really an issue yet, but if we ever had more than one primary graphics plugin, for instance, and different games used different plugins this would be necessary).

I'll also need to have a look at seeing if a TurboSphere configuring plugin for Sphere Studio would be useful. It's all just in plain text config files now. I could have a little code sharing here and use T5 to read and write the config files. I sort of assume that C# has some INI reading/writing capabilities in the core libraries, but it makes sense to only use on solution for files that both the engine and editor muck with to make sure they are readable on both sides.