Skip to main content

News

Topic: Sphere SFML v0.90 (Read 106994 times) previous topic - next topic

0 Members and 4 Guests are viewing this topic.
  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Sphere SFML v0.65alpha
Reply #105
Hmm, you are right. I just looked through the source and saw an explicit call method on a function instance. This might just do the trick! However there must be compilation for the string input since that was created during runtime.

Edit: Okay it is done.
  • Last Edit: July 29, 2013, 07:11:02 pm 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

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Sphere SFML v0.65alpha
Reply #106
Radnen, what exactly do I need to compile this?  Visual Studio gives me an error on Packages.mdproj (never seen an .mdproj extension before, what kind of project is that?) when opening the solution and then if I try to compile it I get a bunch of errors mentioning NUnit...
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Sphere SFML v0.65alpha
Reply #107

Radnen, what exactly do I need to compile this?  Visual Studio gives me an error on Packages.mdproj (never seen an .mdproj extension before, what kind of project is that?) when opening the solution and then if I try to compile it I get a bunch of errors mentioning NUnit...


I used Xamarin studio, it has an integrated nunit test suite and supports a neat packaging solution called "monodevelop packages". Yes, MonoDevelop changed names to Xamarin Studio. I don't know why.

For visual studio you only need nunit for the tests, the .mdproj can be ignored, heck I'm pretty sure the tests can be ignored. But yea that's the only requirement so far. I got it working in visual studio, I like it's debugger better! And it doesn't crash as often. And it doesn't lock up when you test a build, and it's intellisense doesn't get confused if a syntax error occurred earlier in the document (because you were still in the middle of writing code), etc. Xamarin is still in development and I'd even say it's in alpha at times.
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

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Sphere SFML v0.65alpha
Reply #108

I used Xamarin studio, it has an integrated nunit test suite and supports a neat packaging solution called "monodevelop packages". Yes, MonoDevelop changed names to Xamarin Studio. I don't know why.


Hm, if you need NUnit built in, there's an NUnit plugin for Visual Studio 2012 that you can download through Tools->Extensions and Updates that lets NUnit integrate with the VS test explorer (which is nice).

So yeah, I can go install NUnit, that's no problem, it was the .mdproj that threw me for a loop. I'd never seen that type of project before and VS wouldn't open it so I figured I'd be missing something.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Sphere SFML v0.65alpha
Reply #109
So, I was able to get tile animations working with a tile anim helper: it's a list of tiles and their next values in a list. It just goes through these lists updating the tiles. This is how Sphere does it and I think I emulated it well enough. One issue: If you update enough tiles quick enough the fps drops to 800 as if it were drawing each tile individually that's the worst case: every tile on the map animates. Otherwise it's around 4000 FPS for maps that have a standard amount of tile updates: water, grass, etc.

I might get it to go a bit faster, the problem is that once I construct the giant pool of floating point data, it's static. I can either modify all of the vertices to use the bounds of the next animated tile, or I can change the tile image in the texture atlas directly. I decided to change the tile in the atlas directly which is the easiest method since I change it in one place and it's reflected everywhere. But, modifying the texture atlas is a software thing, not a hardware one. I guess it might be possible to use a render texture for the atlas. I'll have to attempt that.

I don't want to directly modify the floating point data since I get the speed for the fact it's static: each frame it doesn't have to change. Only the texture atlas should change. Also for large maps, modifying the texture atlas is always faster than zipping through literally hundreds of thousands of floating point numbers.

Edit: I got up to 3600 fps now if every tile were animating on a map. :) And for smaller maps it hovers right around the 6200 area making it the lightest performance hit for animations yet. I did this by creating a wrapper of the TextureAtlas object and called it the FastTextureAtlas - it's basically a texture atlas that is hardware accelerated. So the downside is it's kind of a memory hog: you need a texture atlas before you need a fasttexture atlas. But a little bit of memory can go a long way in speeding up code. :)
  • Last Edit: July 30, 2013, 05:46:04 pm 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

  • N E O
  • [*][*][*][*][*]
  • Administrator
  • Senior Administrator
Re: Sphere SFML v0.65alpha
Reply #110
Re tile anim speed hit - has there been a test where a tile's animation delay was only one frame? Are the benchmarks about the same as the "animate every tile" benchmarks?

I want to make sure that we can come up with as fast a map blitting algorithm as possible so that when I finally resume the map portion of the Sphere Web Utilities I can put in a decently fast reference implementation the web engines can port even if using a 2D Canvas context instead of an OpenGL context. You say you've got O(l*n) but is there any way we can bring that down to O(l log n) or so for the larger maps? An N-tree algorithm where N=#layers or something?

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Sphere SFML v0.65alpha
Reply #111
I test a full single layer with every tile animating at 1 frame. But I can attempt to create a more rigorous test bed if you want. However, I think that the speed hit is minimized since only the texture source is being updated at least once per frame - no matter if it's one or all tiles being updated.

I'll get back to you soon with a test map and various performance measures.
  • Last Edit: July 31, 2013, 04:58:00 pm 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

  • N E O
  • [*][*][*][*][*]
  • Administrator
  • Senior Administrator
Re: Sphere SFML v0.65alpha
Reply #112
Shiny :)

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Sphere SFML v0.75alpha
Reply #113
x64 Win7 SP1 w/ Intel i5 ivy bridge @ 3.30Ghz
Nvidia 550ti w/ 2GB ram
8GB DDR3-1600 memory.

Sphere-sfml: 4000 fps (GL)
Sphere 1.5: GL: 1390; software: 2750
Sphere 1.6: GL: 1280; software: 2666

You can test the files yourself; they are attached. Several tiles animating at different frequency's and starting from different states. In fact this revealed a bug in my code, but now it's fixed. The above used the fixed version.

Edit:
Now you can test this for yourself with version 0.75alpha :)
  • Last Edit: July 31, 2013, 08:48:02 pm 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

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Sphere SFML v0.75alpha
Reply #114
HashFromFile and HashByteArray now take an extra optional parameter, sha1.

In Sphere 1.6/1.5 the last parameter would be ignored, like so:
Code: (javascript) [Select]

HashFromFile(filename, true); // generates a SHA1 hash in sphere-sfml, and an md5 hash in vanilla.


At least this option will help create better / more secure hashes (despite it's MD5 fallback for vanilla compatibility).

Edit:
Jurassic now gives correct line numbers and filename for bad scripts during runtime. Therefore, it now mimics Sphere in handling errors. :)

Edit:
My map engine is slower to load than Sphere 1.5's since it does a lot of caching for the GPU. Subsequent map loads go by much faster though. I wish Sphere 1.5 did this but the problem with it's graphics abstraction layer is that you can't do neat things with the map engine directly depending on hardware configuration. All you supply to it is how things are drawn, but not how they get drawn (emphasis on the latter).

Edit:
It's now even faster, wow. It seems that clearing a software texture atlas was slower than straight-up rewriting it with image data. It's now 3 times faster, but not that noticeable since it went from basically 300ms to 90ish. It was slow since a texture atlas can be say 1024*1024 but you only use a small portion of it, you rarely use the whole atlas since sprites are packed into it pretty efficiently. It's speedup comes from drawing only what it needs to. BTW, Subsequent loads are around 10ms which is damn fast for a map with 11 entities, animating tiles, 3 layers, and larger than the screen which is a good candidate for an average sphere map.

Edit:
Now surfaces have seen a 10x boost in performance. It rivals Sphere 1.5 now. :D My trick was to use byte arrays and muck around directly with the bytes than go through the SFML abstraction layer. My guess is that it tries to be safe and does a lot of checks /etc that slow it down. I never realized how slow that was though. I always think C# is much slower than C++, but heck it's all about the algorithm, not the language. :P I'm giving the namesake of TurboSphere a run for it's money!
  • Last Edit: August 04, 2013, 05:48:11 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

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Sphere SFML v0.75alpha
Reply #115
Everyone assumes C# is slower because its bytecode, but once the JIT gets ahold of it you're ultimately running native machine code anyway. The only reason C++ can be faster is because you can do a lot more low-level optimization tricks.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: Sphere SFML v0.75alpha
Reply #116

Everyone assumes C# is slower because its bytecode, but once the JIT gets ahold of it you're ultimately running native machine code anyway. The only reason C++ can be faster is because you can do a lot more low-level optimization tricks.


I assume C# tends to be slower because the language is much safer, contains more run time information, and depends on large packages being present. Although this is certainly not a definitive or concrete assumption, it may be reasonable to assume that a larger binary file contains more code to execute, and therefore compared to a smaller binary that performs the same function which performs the same task but has less instructions to execute, can be slower.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Sphere SFML v0.75alpha
Reply #117
True, but you can't exactly compare based on file size alone when one is native machine code and the other contains bytecode (apples and oranges)--indeed, the bytecode may ultimately be JIT'd to the same (or equivalent) code to the native version.  Sure, there are plenty other factors that could slow it down (the aforementioned runtime checks, non-deterministic garbage collection, JIT overhead, etc.) but unless you have super-mission-critical code (in which case, yes, it should be written in a lower-level language), the speed hit is negligible.  Not to mention a lot of runtime checks are turned off when compiled in release mode, as evidenced by the fact that even .NET apps will trigger a native crash ("this program has stopped working") in a lot of cases, in lieu of, say, a NullReferenceException.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Sphere SFML v0.75alpha
Reply #118
Well games do need to be optimized they are considered speed-sensitive. The surface overhaul I did was quick and easy and I could do a lot more interesting things with a byte array than with an image object. True they might be considered similar, both large chunks of RGBA, but the array I can do raw memory transfers and other things that go by faster - especially if you can neglect bounds checking. I know it's dangerous but the way I see it, you are only limited to the code via the JS interface. So long as the JS interface is safe all under-the-hood optimizations no matter how unsafe as long as they are stable, should be okay.

I'm currently trying to fix some camera bugs right now - maps smaller than the screen were crashing. But no longer. Also the camera is a strange beast. In Sphere when you run an ON_LEAVE_* script, it's the camera passing the bounds that triggers it - not the player character. I noticed this when I created a "follow-cam" where it may lag behind the player: not until it catches up with the player it won't fire the map leave code. I have to emulate this behavior too even if it's not correct: zones, triggers, and NPC's use the player characters coordinates to fire events, not the cameras, and not attaching input will turn that behavior off. Not attaching the camera or input and setting the camera past the map bounds will fire the LEAVE code. It seems like that's correct since you technically left the map w/ the camera, but not from a gaming perspective.
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

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Sphere SFML v0.75alpha
Reply #119
That does seem like odd behavior re: leave-scripts, although it makes a certain amount of sense if you assume the real purpose of the leave-script, from a design standpoint, may be to load other stuff when the camera leaves the source map.  e.g. splicing maps together or something? Can Sphere even do that?
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub