Skip to main content

News

  • The forums have now switched to ElkArte, an SMF fork which is more modern and maintained better!

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

1
The factors for both axes should be the same, you want to divide by either wh or hh but not both (I tend to prefer the former).  That was my mistake when I originally wrote the code.
In the original you divided both by wh, I assumed it was a mistake and changed it...
Albrook is a hell of a map, I even remember having trouble getting miniSphere to load that one properly. :o
All I'm processing at the moment is the tile data, I'm ignoring scripts and entities, so I'd hoped it would just work.
2
Albrook from Kefka's Revenge might be a good test map too. Lots of layers and scripts everywhere.
So I tried loading Albrook and just got a black screen, I also tried deleting the nightsky layer in case it was to do with handling alpha wrongly but that had no effect. :( something to fix I guess but hey I'm not done yet.
3
I'm not sure if the effects suit the map, but for testing purposes here is South Figaro from Kefka's revenue being rendered by MEngine with a Scale2x filter and a small mode7 effect.
4
Engine Development / Re: miniSphere 4.8.4
Oh, I didn't realize Oozaru existed, I was just about to start messing with my own implementation, though I was going to start with the 1.x API and work my way up.
1.x was where it all started and I loved it for a while - Sphere 1.1 (at the time) is what I learnt to programme with.
But the v2 API is great too, I'm not intending to do anything around v1 anymore (as long as Fat Cerberus keeps fixing the bugs I find in v2 stuff :P)
5
Sphere General / Re: Sphere v2 API discussion
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.

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.
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.

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.
6
Engine Development / Re: miniSphere 4.8.4
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.
7
Sphere General / Re: Sphere v2 API discussion
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.

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.
Yeah what I'm going to do is use shaders to scale and draw to a surface then convert the surface to a texture.

(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.
8
Engine Development / Re: miniSphere 4.8.4
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)

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.
9
Sphere General / Re: Sphere v2 API discussion
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)
10
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:
https://github.com/fatcerberus/minisphere/blob/v4.8.4/src/minisphere/tileset.c#L154
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.
11
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.
12
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:
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
The very first example map I tried has pixel based obstruction data...

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...
13
Why can rts tiles have individual obstructed pixels?
14
Engine Development / Re: miniSphere 4.8.4
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.
15
Engine Development / Re: miniSphere 4.8.4
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)