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

Re: TurboSphere

Reply #180 –
Quote from: DaVince – on

In current Sphere, grabbing the map is limited to just the visible area on the screen (unless you use some kind of hack).


1. open the editor,
2. create a new project,
3. create a new map that is bigger than ur current screen resolution (tiles * tile size),
4. fill the default map layer with a recognizable pattern,
5. right click a layer on the left hand side of the map editor,
6. mouse over the context menu option: "Export"
7. select the option "Export all visible layers"
8. ???
9. profit:

http://i828.photobucket.com/albums/zz207/the_gimis/programmins/testMapPic.png

edit: added quote

Re: TurboSphere

Reply #181 –
@ninjasword:
I think he meant doing it programmatically, i.e. in-game. To implement special effects or whatnot.

Re: TurboSphere

Reply #182 –
Yes, programatically. Exporting the map image (which I already knew btw ;)) has disadvantages (re-export every time you change the map, have to do it for every map, the project's size gets bigger, you lose animations/the fact that you are running the map engine live...)

Being able to do it on-the-fly means we could create proper Mode7 effects, or play around with the rendered image in some other way.

Re: TurboSphere

Reply #183 –
There is a way through code, but it can get slow to do it per-frame, and it only works on a single layer, but can be used in a loop to capture the whole map:

Code: (javascript) [Select]

	var surfaces = [];
	var c = CreateColor(0, 0, 0, 180);
	var i = GetNumTiles();

	while (i--) {
		var surf = GetTileImage(i).createSurface();
		surfaces.unshift(surf);
	}

	var width = GetLayerWidth(layer);
	var height = GetLayerHeight(layer);
	var l_surf = CreateSurface(width << 4, height << 4, Colors.clear);

	for (var y = 0; y < height; y++) {
		for (var x = 0; x < width; x++) {
			l_surf.blitSurface(surfaces[GetTile(x, y, layer)], x << 4, y << 4);
		}
	}

	return l_surf;


A version exposed through the API would be much, much faster, I hope.

FJ: If you do start the map engine, make it so you can string them together. I've always wanted to have free-form maps like in Pokemon, but cannot do so in the current Sphere. Make it so you can string maps together!
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 #184 –
Radnen: yup, that's the kind of solution I had in mind myself, and also the of thing I'd call hacky. It's strange it's not an engine feature, really.

And I definitely agree on the stringing maps together! Adding 50% to each map that's identical to the next map is hell to do. :P

Re: TurboSphere

Reply #185 –
I too have thought of having maps strung together. It's not difficult at all conceptually, and I do want the ability to do it (easily and cleanly, not through work-arounds in script).

Also, it would be quite simple to add a function that grabbed a portion of the map as an image or surface. Definitely as fast as actually drawing the map, definitely faster than from script.

Re: TurboSphere

Reply #186 –
That's great great great to hear!

By the way... The website is getting a bit old. Maybe just remove the release file from there and make it link to SF too? (While keeping the detailed description (btw update it!), of course... And I think it'd be a good idea to link to your blog from there too ;))

Re: TurboSphere

Reply #187 –
Oh yeah...I completely forgot about the tengu TurboSphere page! I actually have a much better site built that I meant to put up there, but I forgot!

Re: TurboSphere

Reply #188 –
I'm very almost done with 0.3.1. It includes much more fleshed out Sound and SoundEffect objects; Filled, Outlined, and Gradient Circles (with the option for antialiasing); a more robust File object; a better written sound plugin (which only really matters if you like reading the source code...), and a slightly less broken (but still not really usable) map engine plugin, graphics scaling (not perfectly scaled compared to unscaled, but I looked at Sphere's Unix GL driver, and it doesn't look like it uses a much different scaling method).

Pretty much now I need to fix MSVC so that I can actually compile. It seems that it breaks every time I need to install a new .NET redistributable! And I can't use MingW just yet, since they are still making it possible to build V8 as a dynamic library using MingW. I may give Clang a go (TS compiles with it in Linux, I know, and I assume the XCode build that almost worked right for CasioTone used LLVM).

Re: TurboSphere

Reply #189 –
I've uploaded the source for TS 0.3.1. As soon as I get this terrible MSVC version conflict issue resolved on my laptop I'll be able to upload Win32 binaries. But after a close call with my HDD blowing up, I decided to upload what I have right now for safety's sake.

The biggest new thing is that 0.3.1 uses SDL 2.0 and V8 3.19. It was a much less painful process to switch over to SDL 2.0 than I thought it would be, but that's probably helped by the switch to OpenGL, since I was using SDL surfaces for what they really should have been used for at that point.

In addition, circles have been added as graphics primitives, all the old software primitives are now available for use on surfaces (and I fixed a very old bug where lines would not render properly onto surfaces when both X coordinates or both Y coordinates were identical), graphics plugin scaling is supported, the sound plugin is much more fleshed out (almost done, in fact), and several bugs with the file object have been resolved.

Using SDL 2.0 also seems to have doubled the base framerate, there's much less housekeeping overhead now. It should also help with some of the OpenGL compatibility issues.

Interestingly, the all of TurboSphere compiles (with very slight doctoring) using Google's NDK (which is an almost complete C/C++ toolchain for Android), it seems almost all the OpenGL code I wrote is also valid OpenGL ES, and SDL 2.0 has Android support. So there's not really a whole lot stopping this from working on Android, other than the fact that I have no idea exactly what I'm doing with that and just bumbling around with the NDK and Android SDK.

Re: TurboSphere

Reply #191 –
Re future Android support - use RetroArch as an example for coming up with an Android GUI for loading projects into the engine.

Re: TurboSphere

Reply #192 –
Quote from: Radnen – on

What's the framerate of the code here?
https://github.com/Radnen/sphere-sfml/blob/master/Engine/Engine/Startup/scripts/test.js

Just curious.


Huh...not sure. It segfaults on that transformBlit! Which is weird, I've been transformBlitting all over the place and haven't seen that happen yet. I'll see if I can't find out why.

edit: Fixed that problem. Previously, you could try and load an image if a file existed with the same name but a different extension. Then trying to do anything with the image would cause a segfault.

I get (I think, this is hard to say for certain at this kind of rate) 125000 FPS average. <--that's running in Valgrind. I get 400,000 FPS normally.

Why, what kind of FPS do you get?

Re: TurboSphere

Reply #193 –
Not sure now, but damn nowhere near 400000, that can't be right. My tests had been around 11,000 fps, which is consistently 2,000 higher than SphereGL.

I get 9500 FPS on that demo, in Sphere I get 8600 FPS.

I can't even run a single test in your code without a segfault or some other strange glitch. May I consider unit testing? :P

Okay in v0.1.6 I get 3700FPS.
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 #194 –
Quote from: Radnen – on

Not sure now, but damn nowhere near 400000, that can't be right. My tests had been around 11,000 fps, which is consistently 2,000 higher than SphereGL.

I get 9500 FPS on that demo, in Sphere I get 8600 FPS.

I can't even run a single test in your code without a segfault or some other strange glitch. May I consider unit testing? :P


I do test. And I kind of don't, too. My tests are actually pretty limited, and I don't really end up running other folks' scripts very often. If you write scripts the way I do, it runs quite well, I guess. And it doesn't help that this is a pretty new graphics plugin--first to GL (which I can only test on NVidia cards), and now to SDL 2.0. No doubt there are a lot of new bugs, and a lot of old ones showing up as well.

Until I get the map engine going, it's just kind of up to me to write most of the tests it seems, since most games I could test need the map engine. I've been testing my old games, since I rarely used the map engine...but I wrote those. I end up fixing mostly problems that I have.

If you hit a crash, I'd really like to know what you did to make it happen!

Yeah, nevermind that FPS figure. I did the math wrong.

It's 1600 on my laptop. But I only get 1500 with SphereGL on my laptop (which is getting very old). So it sounds pretty comparable.