Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Rhuan
226
I actually wanted to add a function for that like Surface#lock() but I couldn't come up with a way to expose the raw pixel data to JS in a user-friendly way. I'll revisit it at some point, it might be possible to have it return an ArrayBuffer or similar.TBH I''m not sure if there's a need for it as you can do whatever you need with a shader, it just feels counter intuitive to use a shader to fiddle with an image then store the edited image into a variable for later use.
That said, the preferred way to do fancy scaling nowadays is in the fragment shader. I think I've seen hq2x shaders out there, for instance.
If you were to implement it, I'd want it as a direct inverse of the new Texture function except as a surface method probably.
227
Couldn't Sphere run on the web using an individual's browsers JS engine + an implementation of the API in HTML 5? Yes that would require almost a line 1 re-write of the engine but on the face of it I think that would result in better performance and a more sensible system than trying to port the existing codebase.
@Fat Cerberus: what was your plan with Oozaru?
It seems to me that a web implementation and a desktop implementation should be different rather than one being a direct port of the other.
@Fat Cerberus: what was your plan with Oozaru?
It seems to me that a web implementation and a desktop implementation should be different rather than one being a direct port of the other.
228
I actually wanted to add a function for that like Surface#lock() but I couldn't come up with a way to expose the raw pixel data to JS in a user-friendly way. I'll revisit it at some point, it might be possible to have it return an ArrayBuffer or similar.Yeah what I'm going to do is use shaders to scale and draw to a surface then convert the surface to a texture.
That said, the preferred way to do fancy scaling nowadays is in the fragment shader. I think I've seen hq2x shaders out there, for instance.
(I want these done in advance not at runtime as my runtime shader is complex enough as it is, though I may revisit that later. Having the whole map as an atlas drawn using a shape the size of the screen with just 4 vertices seemed like such a good idea when I first thought of it, but getting the coordinates and stuff to work properly with it was... interesting to say the least.
229
ChakraCore on Android would be a project... BUT: https://github.com/Microsoft/ChakraCore/issues/3179 some people apparently made an unofficial port of chakracore (and node.js running on top of chakra) to ios so it can almost certainly be done to android.
I don't think emscripten would be the way to do it though, CC is big.
(Regarding the node.js comment - there's a shim written by microsoft to translate the chakracore run time into the V8 runtime so people can link node.js to chakracore + the shim instead of V8)
I don't think emscripten would be the way to do it though, CC is big.
(Regarding the node.js comment - there's a shim written by microsoft to translate the chakracore run time into the V8 runtime so people can link node.js to chakracore + the shim instead of V8)
If you ever get miniSphere to work on Android, let me know! Allegro is supposed to support it but I couldn't figure out their build systems.I couldn't get Allegro's MacOs build systems working well so i wrote my own xcodeproject/makefile for it in the end when I was getting minisphere to compile. I daren't think what their android system is like.
230
Am I allowed to be annoyed that neither textures nor surfaces are readable in sphere v2?
I was briefly tempted to resort to some v1 functions....
(I want to implement fancy pixel scaling algorithms, but I don't want them at render time I want to do them in advance for a stack of reasons)
BUT it's fine I've worked out a work around that may even work better than what I was planning before, it's just not what people would think of. (but it will be cool)
I was briefly tempted to resort to some v1 functions....
(I want to implement fancy pixel scaling algorithms, but I don't want them at render time I want to do them in advance for a stack of reasons)
BUT it's fine I've worked out a work around that may even work better than what I was planning before, it's just not what people would think of. (but it will be cool)
231
Hmm... not sure where I picked up the information if it's not in tileset.rts.txt, since miniSphere has code to load the tile names:Test map and tileset I was using are from spectacles so I'm guessing you either saw it in tileset.cpp or you had the same problem and fixed it when you were first working on miniSphere.
https://github.com/fatcerberus/minisphere/blob/v4.8.4/src/minisphere/tileset.c#L154
232
Oh I'm wrong - they're not pixels, it's just it lets you have segments of 1 pixel only.
And I found something not in tileset.rts.txt, a tile in an rts file can optionally have a name, the tileset I was trying to read had a named tile in it which was throwing off my reader. I found this by looking at tileset.cpp.
tileset.rts.txt states that the tile information block ends with 22 reserved bytes, conversely tileset.cpp has a 2 byte name_length then a byte for "terraformed" (seemingly not used) then 19 bytes reserved. THEN after that it looks for a name of length: name_length. (the length can be 0 in which case it looks for nothing).
tileset.rts.txt says nothing of this name.
And I found something not in tileset.rts.txt, a tile in an rts file can optionally have a name, the tileset I was trying to read had a named tile in it which was throwing off my reader. I found this by looking at tileset.cpp.
tileset.rts.txt states that the tile information block ends with 22 reserved bytes, conversely tileset.cpp has a 2 byte name_length then a byte for "terraformed" (seemingly not used) then 19 bytes reserved. THEN after that it looks for a name of length: name_length. (the length can be 0 in which case it looks for nothing).
tileset.rts.txt says nothing of this name.
233
No idea, I never implemented it in miniSphere and haven't had any compatibility issues, I think even the Sphere 1.5 editor only supports line segment-based obstruction. The RTS spec says:The very first example map I tried has pixel based obstruction data...Code: [Select]byte blocked; // 0 = no obstruction data, 1 = old obstruction data, 2 = new obstruction data
So I just assumed it was deprecated.
edit: Yep, Sphere 1.x ignores it too:
https://github.com/sphere-group/sphere/blob/master/sphere/source/common/Tileset.cpp#L513-L517
And opening it in the 1.5 editor allows me to edit it and keep it.
If you make a new tileset you don't it get it but if you use an old one it's kept. And I want to get this to work now...
234
Why can rts tiles have individual obstructed pixels?
235
Regarding the abstraction layer: I wanted to get it out of the way first, to avoid making the same mistake I made with Duktape where there was no abstraction to begin with and implementing the extra layer now would be prohibitively time-consuming relative to the benefits. It's bad enough I'm going to have to refactor everything in pegasus.c and vanilla.c (and probably some stuff in map_engine.c too). The v1 and v2 APIs taken together account for about 500-600 functions, methods and properties, the only saving grace is going to be that those are mostly all stubs with the actual work done deeper in the engine.I could help with the refactoring if you'd like, once you've got the basic framework set up and done a few functions I'm sure I'd be able to match the style and basic methodology. Let me know if you want to split it.
236
Quote from: Fat Cerberus link=msg=9964
The js_value_unref()s are an unfortunate side effect of the abstraction--I'm not longer passing around the JsRefs directly, so I need to manage the object lifetime manually.Hmm, will that cause a problem with garbage collection? I can see it getting annoying at least, anyway you could add at least some of them to the abstraction layer?
I assumed you'd have got a function callback set up sooner I guess you focussed on the abstraction layer first?
Good work nonetheless.
(I wrote an equivalent test for jsc on Saturday but without any abstraction, which meant it was much quicker to do but ultimately much less useful I suppose)
237
If you're striving for full Sphere v1 compatibility, you actually want to run map/entity scripts with `EvaluateScript()`, making them into functions (they get their own scope) or using `eval()` (uses scope of caller in ES5+) will change the behavior.i'm trying to avoid using any of the v1 api, I want all of this stuff to work if you build sphere without vanilla.c
The difference if you're curious is that Sphere 1.x runs all scripts as top-level program code, the same way browsers handle multiple scripts.
This, incidentally, is the reason I made SetUpdateScript() etc. be able to accept a function instead of a string, since it let's you access local variables in your update/render/person scripts that way.
I'm not looking to emulate v1 the idea of the compatability shim I'm thinking of is to make it do enough so that anyone with a v1 project who wants to switch to v2 can use their existing maps without going through editing them all; their main script files will obviously need some updates.
238
Albrook from Kefka's Revenge might be a good test map too. Lots of layers and scripts everywhere.Map and entity scripts are scaring me slightly, roughly I'm planning on using the function constructor to parse them and I can set up execution conditions easily enough my concern is I'd like to make v1 maps work which means I need to implement a shim over the top of all the v1 map/entity related functions AND provide that shim to all the map and entity scripts, I can do it but I haven't worked out an efficient way to do it yet (if you've read my code you'll know what I think of inefficiencies...)
I also need a mechanism for passing other functions and variables to those scripts as by default in v2 they'll be run with no access to anything global.
239
A scaling filter could be good. A lot of emulators use them for nice upscaling. Something more modern like EPX/Scale2×/AdvMAME2× might be good here.Hmm... New planned feature for MEngine and SEngine
240
Please could someone suggest some really massive/complicated .rmp files I can test with?
Whilst I'm aiming at supporting Tiled maps as well as .rmp ones I want to support .rmp fully so would be good to have some horrible test cases.
Whilst I'm aiming at supporting Tiled maps as well as .rmp ones I want to support .rmp fully so would be good to have some horrible test cases.