Mist: UE-inspired 2D engine [in-dev]

[Delfigamer]

Well, that interesting. Too bad I that cannot pay for beer over there.   
I got an idea for this game but need a real thing btw.

How long this coding would finish anyway? Cant wait to start. 

I don't know.
I've noticed I am kinda perfectionist for code - most of Core here is result of nearly 5 full rewritings; Engine had experienced only one; .lua scripts as newest code are probably yet to be rewritten.
So, the most optimistic estimate is 1 month. -_-

[The Noodles Guy]

Datmaku.

The page cannot be found, either.

PS, your english is really good :derp:

[Delfigamer]

The page cannot be found, either.

Eh?

PS, your english is really good :derp:

:yukkuri:

[Delfigamer]

Whoa look I post here again.

Lately I was working on a more convenient packaging system than what was already here. The main difference between them is that a new one is asynchronous. That means, while the kernel deals with HDD, loading/saving code doesn't block the whole execution. Instead, it returns control to the main program shortly after asking kernel32.dll for I/O operation, and then silently waits for its completion while the main program executes another useful code, e. g. graphics. When the operation completes, the kernel notifies its client and loading/saving code continues its execution with acquired data.
Simply, I don't have to wait for the whole map to load before drawing the next frame in an animation.

I don't think anybody here is interested how to make Windows behave this way, but just in case somebody is - "Synchronization and Overlapped Input and Output" article on MSDN.

on: 22-04-2013
the most optimistic estimate is 1 month

And it's still not done. :V So now you know what to (not) expect. :fail:

[Delfigamer]

JAJAJAJA!
~~~ EPIC THREAD REVIVAL TIME ~~~
JAJAJAJA!

* shameless bump *
Hey guys, I think I won't do Touhou-like shmup. :derp:

Well, as you may see, I've built a simple platform for 2D sprite-based games. When writing the code, I've kept in mind possibility of adapting it to other types of gameplay, though main target was still danmaku.
Now, building just another shmup doesn't seem that exciting for me. Instead, I'm going to switch to RPG-like 2D shooter. I've never seen such type of game before, and I don't know proper name of the genre (though I won't wonder if you point out similar already done game like this). Basically, it is like Unreal [Tournament] on plane, where dodging factor is raises more, thus introducing some concepts from shmups, but overall action is still intended to take place in conventional game maps with space layout where player makes his path like in ordinary first-person things.

I may try to finish basic danmaku code and make a couple of example stages for reference if you ask. However, I won't extend it to full Touhoi-like game.

Still surprisingly actual. Well, aside from "I've built" bit, I'm still building... it.
What this it now is my new full rewrite from scratch.
The engine consists of two parts: native code, written on C++11, and interpreted one, in my beloved little cute Lua.
Native code is currently intended to compile on whopping two platforms: Windows/x86 and Android/ARMv7 (basically 2 my computers lol).
The native part handles everything that Lua may be bad at, and probably something more. This includes:
- setting up a window and receiving messages from OS;
- graphics system: for Lua side, it exposes a nice set of objects like Texture, Shape, SpriteField and others, when rendering, they load OpenGL with useful work;
- resource system: as scripts are concerned, there is an abstract "IO" concept which is an address space which we may read from and write to, there is a "File" implementation of this concept, there is a "Package" format which takes a single large IO and turns it into a resource database, providing each one with its own pair of IOs and some metadata, there's also a little PNGReadTask because libpng's API is horrible and boundaries are good;
- math library, which now is still empty.
One feature that I'm proud of is that script execution (essentially all application/game logic) is done in parallel to rendering in a different thread, and the game doesn't seem to crash very often because of concurrency problems (all hail boundaries).
I love boundaries.
This is still very early in development, but now it can produce some cute effects, so I've decided to finally announce that I'm not actually dead and to show this little thing.

As usual in this thread, no, you still cannot use this for any actual game because
1) there are so many neccessary features missing that I don't even
2) all APIs will probably change completely like 10 or 100 times during further development and architecture refinement
3) Valve time ; I totally can understand why they take so long to make anything, but hopefully, this one will have been worth the weight. Thanks, and have fun.

P. S. Ask anything, I'll probably have to make a proper documentation some day anyway, so having some bit ready by the time won't hurt.

[Sparen]

Sometimes the new push mes end up below existing ones and sometimes end up above existing ones. This function is not particularly precise and may result in different outcomes in the future.

[Delfigamer]

Didn't bother with draw order at the time, so the sprites are drawn as std::unordered_multiset arranges them, which is quite... unordered. The objective was to make well-formed vertex+index arrays, it seems I succeeded.
Now, I'll make them stay in order, like shapes do already (clearing the screen never happens after drawing sprites), this is not a hard task.
So... it's just as planned? I think it is.
________


I am quite content with 6.6 microseconds/sprite. On my 2*1.67GHz netbook with 64MB Intel GMA not-even-a-videocard. I have a feeling that even my tablet can do better.
And notice how everything's in order now: arrows on the very top, then "push me", and swarms of little crosses form a background.
Here it is.
If you still want to spawn ordered hecks, copy "output/scripts/index-cmd/page.lua" over from the older archive to this new one. You will see that now, sprites with same "order" value are further sorted by their creation time, with most recent being on top.

[Delfigamer]

If you haven't noticed my rants in the Cafe's programming thread, here's the news: I'm building a Direct3D implementation of the graphics module, because GMA 3150 sucks.

While I was remembering how to poot texture here, I realized that I don't exactly need some elaborate shaders.
The original idea was to implement a special kind of normal-mapped lightning. The way I imagine it, it's done exclusively with texture operations. And what do we have in D3D? Texture stages!
In D3D9, you can enable up to 8 independent samplers. Maybe some hardware allows more, but 8 samplers are also guaranteed by GLES, so I'll stick to this number. Each texture stage may be assigned its own texture coordinate set (you can pack multiple in a single vertex in both D3D and GLES), texcoord transformation matrix and of course own texture itself. Then, when processing a fragment, its color is adjusted by each stage in a certain way: it may be just replaced with, it may be added, modulated and, what's very good, dot-multiplied with either a value sampled from a corresponding texture or a uniform color value. You also can order a separate handling of alpha value... neat.

So, instead of allowing the scripts to load and set their own shaders, I've decided to expose a similar API. In D3D, it will be translated almost directly into its methods. In GLES, it'll probably make a runtime-generated fragment shader and fill its uniforms with neccessary values.

Considering that rendering-to-texture is still a must, one would still be able to make some cool effects with this system.
Oh, and glowing bullets is not an only idea I have in mind :3

[Delfigamer]

So, in this March, I've added another similarity with Unreal Engine - it now has several different implementations of the graphics subsystem. Now, it's still only Direct3D and OpenGL ES; but who knows, maybe in 10 years, some wizard will come and implement another variant?
With some additional tweaking, it's even possible to detach it into a separate dll/so, like in real UE; but there's no need for that right now, so it won't actually happen any time soon.

I love how this "Pixel program" concept came out. GLES puts surprisingly strict limitations on fragment shaders, namely: a conforming implementation may have as little as 16 uniforms. That's just tiny. Every sampler requires a singe uniform vector. A constant colour is another vector. And a single matrix occupies whole 4 uniforms. Well, I could force the matrices to be 3*3, making them a little slimmer. But, remember, the engine still promises about 8 texture stages.
I'd already limited pixel programs to no more than 2 different matrices, not counting the identity, but, it seems, when I return to ES, I'd have to make some other restrictions to make it able to produce manageable shaders.
On the other hand, though, each sprite can have two independent sets of texture coordinates, so this might help to still make something fancy even with just 16 uniforms and a single shader.

Anyway, that's how it looks now:

And here's the archive. You may want to look at scripts/index-cmd/page.lua and try something other with it.

Also, with these pixel-programs, I can already implement something resembling a sprite-based lighting system I've been dreaming about. Hint: Op_DotProduct, it makes miracles.

[Delfigamer]

Also, with these pixel-programs, I can already implement something resembling a sprite-based lighting system I've been dreaming about.

Yeah that's what I'm talking about.
Look at that sexy plates oh yeah

[Delfigamer]

I find pushing some silver-ish buttons and looking how the text below changes oddly satisfying.
I wonder if a father has similar feels when his baby makes their first steps? Though, contemporary fathers usually don't develop their children's muscle tissues, their placement in arms and other engineering stuff like that, while I did implement some utility to build and utilize bitmap fonts.
I mean, literally, when you press a button, the engine gets a place in a special text-dedicated texture, renders each letter by its pixels, and then draws a quad with this texture applied.
Also, some bonus utility in the package. Hint: client-win32 silent=true indexmodule='index-img' alfile='al.lua'.
What do you think, is it finally time to start making something actually resembling a game? Well, probably it is.

P. S. Firefox, stop, that's embarassing. You can break youself if you crash that often.

[Delfigamer]

Do you remember me, RaNGE? I guess you don't, but that's okay.
Just dropping there to say I have a GitHub rep now. It's not like I was keeping the sources in secret before, but now you don't even need to ask to look at this.
Well, back to being locally dead, I suppose.

[Delfigamer]

Heyyy it's me again. Well, that wasn't that long.

So, here is a little demo. "Fireflies", run on Mist version "not quite a wheel already, not quite a Porsche yet". Unpack, run "client-win64", click on the screen many times, enjoy.

[james7132]

Perhaps some VSync is needed. Right now the demo you just released runs at 6000 fps on my desktop and over a sustained period of time used 35% of my CPU. That's ~50-100 times the computation needed for keeping it smooth.

[tyrz_939]

Perhaps some VSync is needed. Right now the demo you just released runs at 6000 fps on my desktop and over a sustained period of time used 35% of my CPU. That's ~50-100 times the computation needed for keeping it smooth.

I think it's more of a performance demonstration.
In my games debug mode I can uncap the FPS while holding tab, it's useful for gauging performance.

[Delfigamer]

I think it's more of a performance demonstration.
In my games debug mode I can uncap the FPS while holding tab, it's useful for gauging performance.

Yes, I've decided not to cap the engine to see how it performs.

Perhaps some VSync is needed. Right now the demo you just released runs at 6000 fps on my desktop and over a sustained period of time used 35% of my CPU. That's ~50-100 times the computation needed for keeping it smooth.

Strange, on my notebook it runs only at ~200FPS when plugged and ~100FPS otherwise. Maybe you're giving me the second number?
Graphics and the main logic run in two separate threads, and are updated asynchronously, so the window title shows two different numbers: one for how many times D3DDevice9::Present has been called, and another for how many times a "tick" event has been issued to the Lua side.
Code for the flares themselves caps the updates at 100Hz, though, so most of the time those ticks do nothing useful.

I have added config options to enable vsync and to limit the frequency at which the host sends those "tick" events, so, whenever there'll be a next update, this time you'll be able to use them.

[james7132]

Strange, on my notebook it runs only at ~200FPS when plugged and ~100FPS otherwise. Maybe you're giving me the second number?

[Delfigamer]

Bloody hell.
Hm, that's probably because of differences between Win8 and Win10.
Well, in the next build, a user can cap both of these numbers, so it's not a very big deal, I think.