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

Re: TurboSphere

Reply #135 –
Once again, TurboSphere has a map engine. I've worked out two different methods for drawing the map--an unoptimized draw, a more optimized RLE and chunking renderer (about 20% more efficient on a good day and with a good map for it), and I'm working on a much better buffer based renderer. The unoptimized renderer mainly exists to test out new features and for debugging. It works perfectly, and is so simple it pretty much has to work perfectly. The RLE/Chunking renderer is nice because it is faster, (it looks for contiguous chunks of the same tile to all draw at once, and failing those draws contiguous strips of the same tile all at once) and does not need any extensions (which apparently some drivers don't have? I'll have to research this a lot more, and see if I have any old Intel-GPU laptops around to test things on). The new engine doesn't handle much beyond the map and sprites yet, but all in good time. It looks like drawing a 480x320 screen of 16x16 tiles with 3 layers takes about 0.5 ms with the RLE/Chunking renderer, and calculating the strips and chunks is easily as fast as an unoptimized draw alone is, so that seems pretty good for a fallback method. The buffer based renderer will definitely be faster as well.

It is quite simple to compile the included scripts in the maps at load time with V8. I'm not sure this will actually be any faster than the way 1.5/1.6 is, but it seems like it should be. At the very least, this grants the embedded scripts the same speed benefits of stand alone script files.

I would also like to add the ability to set the map engine scripts using functions directly instead of strings. It seems much nicer that way, and it's easily done on the engine side.

About the Sphere filetypes...I don't understand why the tileset files (and embedded tilesets in maps) are the way they are. Unlike every other Sphere file format, the tiles are each listed in bitmap format, and then after all the tiles' images we begin with their headers (or I guess footers in this case). Why doesn't each info block follow or precede the tile's data? I don't know.

Re: TurboSphere

Reply #136 –
+1 on the chunking, my Sphere Studio does that, and makes maps load and draw quite fast.

The tileset was quite strange to load for me. Did you come across the error in which a tiles name is stored after it's header? The name itself is not in the header (primarily because the header is fixed length and the string is not). The name comes after the header (between the current one and the next). The header also stores the length of the name after the obstructions count (it's a short), that leaves 20 bytes remaining rather than the 22 the docs say.

Header
name
Header
name

If the names are empty, then you can load them without the error, but if you load tiles that have names, well, then you come across the error, It's not in the latest docs, this I found out when I worked on it. I've been meaning to update the github docs, though.

Edit:
Here's how I saved a tileset in the Sphere Studio:
https://github.com/Radnen/spherestudio/blob/master/Sphere.Core/Tileset.cs#L170-186

and the new tileset spec:
https://github.com/sphere-group/sphere/blob/v1.6/sphere/docs/internal/tileset.rts.txt
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 #137 –
Huh, I haven't come across any tiles with names stored (at least not interspersed with the headers). I'll have to add support for that. And by the 'latest' docs, you mean the ones that are dated January of 1999?  :P

If you want to make it so your editor can save them a new way (a version 2 of the spec), I'd gladly add support for it.

The way I'd like to see it:

Header
Image
Name/Strings

Header
Image
Name/Strings

...

Like all the other Sphere filetypes. Every string is 2 bytes of length info, and then characters for the specified length. It would be consistent for the names (stroke strings section) to follow the headers. It mainly bothers me that the headers are not interleaved with the data, every other filetype follows that format, and it makes things more complicated that it doesn't work that way.

If you are updating the docs, a note on what is meant by 'word', etc. would be nice. It became clear pretty quick when I started trying to read the files, but when I see 'word' I think '32 bits', since that's what the basic data types are in most languages these days, even in 64-bit systems.

Re: TurboSphere

Reply #138 –
'word' is 16-bit, 'dword' is 32-bit, 'qword' is 64-bit. It's been this way for decades.

Re: TurboSphere

Reply #139 –
I'm now aware. DWord and QWord are very self explanatory if you know the word length.

I'm sure that if you are actually using the Sphere source that the filetype docs are much more useful.

Re: TurboSphere

Reply #140 –
Quote
Does the OpenGL plugin for TS fix the off-by-one errors in 2X scaling mode? That's my only issue with it in 1.5, it causes one-pixel gaps to appear between adjacent objects.


I noticed no-one answered this. Im pretty certain Kyuu fixed this at my request. He sent me a new .dll for it. I lost it a while back and someone posted another copy and im pretty certain im using it now on this PC so we can post it up here

It might be this one?

** EDIT ** and why am I a "newbie" lol

** FURTHER ** I was gonna say if you need PCs/Laptops to test on I have a bunch here.

PC on XP - pretty old, still has a parallel port which has been very useful for me
PC on Win 7 - About 4 years old - on AMD graphics
PC on Win 8 - 3 months old on Nvidea
Laptop on XP - Also about 7 years old ATI Radeon I think
Laptop on Win 8 - 2 years old on ATI Radeon

My friend and step dad have various Linux distributions also

Re: TurboSphere

Reply #141 –
It would be very cool if you could test the latest release from sourceforge on the NVidia laptop and also on an ATI laptop. I've ascertained that it definitely doesn't work with Intel graphics, but it should almost definitely work on NVidia computers. I don't know about ATI machines.

As far as TurboSphere on Linux goes...it works with scons, but you *do* need to build and install V8 manually (as in compile it and then copy it to `/usr/lib[64]/turbosphere` before using scons on TurboSphere). Directions for all that (except the manual copying) is in the docs folder.

Re: TurboSphere

Reply #142 –
Well, I was going to wait to make a release until I got the map engine working with VBOs (for speed)...but I did a little test.

Drawing using RLE-ing on the tiles, with a 2 layer map: 1300 FPS.
Drawing using RLE-ing on the tiles, with a 1 layer map: 1400 FPS.

Just looping and counting blank frames for the same amount of time: 2400 FPS.

So with that in mind that speed is very acceptable. Just the drawing is more than half as fast as...well, doing nothing at all.

The map engine is a lot like what I released back in 0.1.0, except that now it supports loading any map that the editor makes, and can actually draw multiple layers. I'm working on adding sprite support and animated tiles next.

I need to unpack my desktop to be able to compile on Windows, but I'll get to that this weekend likely.

Re: TurboSphere

Reply #143 –
I spent a few hours last night getting this to compile on OS X. I haven't gotten it working correctly yet, as it crashes in the word-wrap function because of a memory issue. But it compiles! I'll have some patches for you later. The main issues were not including the Cocoa/OpenGL frameworks, and libv8 wasn't included when building configmanager.

edit: the memory issue is in TS_BMPFont::wordWrapString(const char *t, int w, int* num), a SIGABRT is thrown on one of the realloc calls.

Also T5_file::T5_file(const char*file) was failing to read any data from the settings files - I fixed this by seeking to the beginning of the file after opening. My guess is this is caused by the file being opened twice (once to check the file exists, and once to read it) but I'm not sure.
 

Re: TurboSphere

Reply #144 –
Which version of OS X, 10.6 or one of the later ones?

Re: TurboSphere

Reply #145 –
10.8.2

Re: TurboSphere

Reply #146 –
Is it possible to build w/the 10.6 SDK on your setup or is that more trouble than it's worth? My Macbook Pro is early 2006, so I can't update it later than the last 10.6 and I don't have a Hackintosh setup w/10.7 or 10.8 :(

Re: TurboSphere

Reply #147 –
I'm not sure it is possible, I've tried something similar before.

Here's a pull request with the changes I made, anyway:

https://github.com/FlyingJester/TurboSphere/pull/10

At this point it gets to here:



(edit: sometimes it actually gets a bit further.)

Then receives a SIGABRT. Here's some of the logging output and a gdb backtrace:

Code: [Select]
[ttffontGL] DrawText Info: Binding string Do a barrel roll! to cache slot 0.
JS Result will be passed.
310
[ttffontGL] DrawText Info: Binding string Do a barrel roll! With TTF Fonts! to cache slot 1.
turbosphere(57676,0x7fff71b79180) malloc: *** error for object 0x1006528f0: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug

Program received signal SIGABRT, Aborted.
0x00007fff891f8212 in __pthread_kill ()
(gdb) backtrace
#0  0x00007fff891f8212 in __pthread_kill ()
#1  0x00007fff8aa2aaf4 in pthread_kill ()
#2  0x00007fff8aa6edce in abort ()
#3  0x00007fff8aa4a8a5 in szone_error ()
#4  0x00007fff8aa4bcc6 in tiny_free_list_remove_ptr ()
#5  0x00007fff8aa46092 in szone_realloc ()
#6  0x00007fff8aa4254a in malloc_zone_realloc ()
#7  0x00007fff8aa42cac in realloc ()
#8  0x00000001015ac1da in TS_BMPFont::wordWrapString (this=0x7fff5fbfe740, t=0x7fff5fbfe740 "??_?", w=1606412096, num=0x7fff5fbfe740) at bmpfont.cpp:377
#9  0x00000001015aeac3 in TS_BMPdrawTextBox (args=@0x7fff5fbfe774) at bmpfont.cpp:470
#10 0x0000000100041b73 in v8::internal::Builtin_HandleApiCall ()
#11 0x000010376540654e in ?? ()
#12 0x000010376542dd55 in ?? ()
#13 0x0000103765425367 in ?? ()
#14 0x0000103765412017 in ?? ()
#15 0x0000000100068e2d in v8::internal::Invoke ()
#16 0x000000010001fd73 in v8::Function::Call ()
#17 0x0000000100001be7 in SDL_main (argc=8563848, argv=0x100862000) at engine.cpp:146
#18 0x000000010000311a in -[SDLMain applicationDidFinishLaunching:] ()
#19 0x00007fff874e947a in _CFXNotificationPost ()
#20 0x00007fff87952846 in -[NSNotificationCenter postNotificationName:object:userInfo:] ()
#21 0x00007fff861b760d in -[NSApplication _postDidFinishNotification] ()
#22 0x00007fff861b7346 in -[NSApplication _sendFinishLaunchingNotification] ()
#23 0x00007fff861b4532 in -[NSApplication(NSAppleEventHandling) _handleAEOpenEvent:] ()
#24 0x00007fff861b412c in -[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] ()
#25 0x00007fff8796c12b in -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] ()
#26 0x00007fff8796bf8d in _NSAppleEventManagerGenericHandler ()
#27 0x00007fff86d35b48 in aeDispatchAppleEvent ()
#28 0x00007fff86d359a9 in dispatchEventAndSendReply ()
#29 0x00007fff86d35869 in aeProcessAppleEvent ()
#30 0x00007fff82a0d8e9 in AEProcessAppleEvent ()
#31 0x00007fff861b0916 in _DPSNextEvent ()
#32 0x00007fff861afed2 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#33 0x00007fff861a7283 in -[NSApplication run] ()
#34 0x0000000100003725 in main ()

Re: TurboSphere

Reply #148 –
I'm in a place with terrible internet, or else I would push the fix for wordWrapString (that I did about a month ago), and all the other stuff I've changed. The problem is (or was) that the function BMPFont.addLine doesn't reassign one of the addresses that it reallocs.

This has hung around because realloc very rarely changes the address on Linux, but almost always does on Windows (and apparently OS X as well). It's just random chance when it doesn't crash. Since I do almost all the developing in Linux, I very rarely encounter it while I'm working on TurboSphere, so this bug has hung around a lot longer than I'd like.

Very awesome! I didn't expect to see this working even a little in OS X for a long time!

I'm also pleasantly surprised that plugin loading works on OS X. I didn't really write it with anything but Windows and Linux in mind.

Re: TurboSphere

Reply #149 –
@casiotone - What's your tool chain on OS X? I want to make a note of whether I should use old XCode 3.2.x to build on 10.6 or use MacPorts gcc or something when I go back to my Macbook.