Maidens of the Kaleidoscope
~Hakurei Shrine~ => Rika and Nitori's Garage Experiments => Topic started by: Delfigamer on September 06, 2012, 02:24:50 PM
-
No longer actual, see here (https://www.shrinemaiden.org/forum/index.php/topic,13364.msg1167410.html#msg1167410) for the current progress.
Old variant; in fact, this was my very first post in there:
Last year I was making an engine for danmaku. (I see, you use word "danmaku", so I'll use this word except for engine terms that are explicitly declared as "Dammaku".)
When it was very raw, I was posting progress at sos-dan.ru theme (http://forum.sos-dan.ru/showthread.php?t=474&page=13). Now it is... um... raw too, but, since you can shoot enemies now, one could use it for some experiments.
Actually I don't know what Danmakufu's inside (and TH's one as well) is, but I'm sure architecture is very different, I can describe it if you want.
Archive with all game's content is here. [2015 patch: (http://i.imgur.com/7IuRsvb.png) this is not working]
To run it, you should execute "Output\Engine\Client.exe".
...Also, if you want to know, it's written in Delphi and uses Lua.
P.S. Uh, my English may be really weird somewhen, keep it in mind and don't wonder if some strange word/sentence is occurred. -_-"
-
I have a hard time understanding what's going on with the enemies' bullets. Why do their small bullets transform into rings? Am I supposed to avoid those things or are they just a visual effect? Otherwise it looks like a great start.
Having a look at Danmakufu's scripting language may give you some ideas how to handle things. It generally works by creating its own objects and giving them various common methods (initialize, update, render, deinit...) where the scripter can specify the behavior themselves. There's no "magic algorithm" to it through which data is passed and bullet patterns come out - they are "programmed" much in the same way as any other program would be.
-
their small bullets transform into rings
:/
Rings are test enemies, they shoot with test attack, three simply aimed bullets in a row.
Stage (currently that's the only thing where Lua is used) is constantly repeating group of those enemies.
http://pastebin.com/bfgCJkdF
Otherwise it looks like a great start.
Oh. It is only test script that is used to debug main game algorhytms.
Having a look at Danmakufu's scripting language may give you some ideas how to handle things. It generally works by creating its own objects and giving them various common methods (initialize, update, render, deinit...) where the scripter can specify the behavior themselves. There's no "magic algorithm" to it through which data is passed and bullet patterns come out - they are "programmed" much in the same way as any other program would be.
Ow. My engine does similar things, except for content implementation that is DLL with certain functions.
http://pastebin.com/JQWJ1gcN
________
Oh, just realized what rings you are writing about. That shapes are a bullet destroying animations. Bullets also can have "maximum lifetime" value, it's set to about 1sec to these ones; that's why they are destroyed after certaint time arter creating.
-
I'm currently building... let's name it filesystem override, that system will let me to pack contents in archives without engine losing ability to reach it.
Comparingly stable version is available at the link in first post. From previous one that has player's option support.
Archive with all game's content is here (https://www.dropbox.com/s/mew67h2llf6t0px/Output.rar?dl=0).
-
Hmmm why do the test attack disappears after some seconds. I tried to change some attack file but the game become too slow :V
So I played a little with the stage files, it's pretty interesting, looking for it here ;)
(http://imageshack.us/a/img802/2239/waveshot.jpg)
-
Hmmm why do the test attack disappears after some seconds. I tried to change some attack file but the game become too slow :V
So I played a little with the stage files, it's pretty interesting, looking for it here ;)
:3
Most values have defaults defined in code. Though, you can change them in .bulletattacks, .enemies and .playermain files.
Here is quotes from source. Too lazy to rewrite it; I think you'll understand however.
http://pastebin.com/ZWM097Zh
http://pastebin.com/KYiR2chb
http://pastebin.com/D2yk7hNw
...Uh. I wonder if it'll be used by somebody.
________
UPD
Moved all this code to pastebin. Have a nice day. :3
-
Warning: this topic has not been posted in for at least 14 days.
Unless you're sure you want to reply, please consider starting a new topic.
After lo-ong time of raymoo laziness I finally managed to launch Delphi and continue rewriting game's core. Most of its structures are updated; the thing that's left is the Great Main Object, fatness of which (http://pastebin.com/Sss4h3kS) made me to do all this rewriting.
Why I am posting it here? Just to assure everyone (and myself at first -_-) that this project is not dead.
-
Hey Delfigamer did you do a stress test about the max number of bullets that your game engine can bear in the screen? I did a little bullet hell engine in Unity3D 4fun but it could only bear 100 bullets in the screen :P
-
820 enemies with default shooting pattern (http://pastebin.com/ekf8yf95) maintained with FPS ~55, if player doesn't shoot. ~15 otherwise, because homing sucks.
________
So, I've finally divided ICoreWindow into ICore and IWindow (http://pastebin.com/dYEVJaHQ) (lol). Now I can update rest of core (fonts and corresponding sprite), move menu-stuff into it and return dammaku itself.
I now think where to define game entities' behaviour. In the stable version that still lies in my dropbox, attacks, enemies and that stuff are represented by native code in external libraries (you can find "DefaultWhatever.dll"s in game's content, that's it). Though, as time from its writing passed, I had attached Lua to my engine, and now, theoretically, I'm able to use it for the whole game's description.
But, Lua lacks some features that would be useful for describing the entities, while Delphi have enough of them, if not too many.
What ideas do you have on this?
-
So, now I have the very boring and uninteresting tumblr which probably will describe how this engine is structured, and how this structure is rewrited. If you don't know what do COM and DLL mean, you probably won't find any useful information here, except for the fact I'm still working on this.
BTW, while I post here, rewrited part now shows FPS again. :derp:
-
Oh cool, I was thinking to create a new post talking about general danmaku programing (excluding Danmakufuu) to talk about common data structures (bullets, enemies, stage scripts, etc) and functions to control their behaviour :P
-
That's simple. Stable version has this. (http://pastebin.com/vZtcZ6Bu) :V
Though, now I'm going to use Lua for this.
-
Hmmm what controls the bullet movement pattern is the TAttack struct?
-
It is your fault to ask such deep question. Now read this.
-
So, it is possible to create danmaku which will erase a random file from ?My Documents? on every hit.
Wat? I always knew that Danmaku isn't a safe game :V
And the code works someway like I was thinking how it works. Interesting. Also since you can do "anything", you can call generic math functions to do the bullet movement, so it is easy to do even a "heart" movement (http://en.wikipedia.org/wiki/Cardioid) :)
Did you start to implement the boss system code? Spellcards and cia
PS: There are some typing errors on the article, fix it ;o
-
No, I didn'n start it, I'm just rewriting the code now, otherwise inserting anything new would became very very painful and unpleasant.
I once tried to build proper parametric formula for logarithmic spiral, but ended being unable to find an integral for some assy function.
And you'll be shocked, but Lua has all this mathy stuff too.
-
I've considered to move all controls (now only button and menu) into Core.dll, since they are just as standart as texture sprite.
So, I've made new button class. But, when I tried to use it... button's sprite hadn't been showed. User couldn't see any "button" on the screen.
Where was the problem? Simple.
- UList.TCustomListIterator.MoveNext: when deciding whether to disable the iterator, I've written "if Result" instead of "if not Result" (Result indicates if next iteration is possible). So, instead of finishing iterating on last item, that condition forces the iterator to stop after first one.
- UUpdateTimer.TUpdateTimer.Update: time in the Core flows through hierarchical tree of timer nodes, each of them has its own factor by which time of parent node is multiplied, and that tree is separated from other structures (e. g. visible entity list). Each object that may need to do timed actions creates its own timer node, and attaches its own method to this node. When a particular node receives a request to advance in time, it applies its time factor, calls attached method (if one exists) and then passes that request to child nodes. List of child nodes is UList.TList, which used the broken iterator. So, only first node got the request, while others weren't touched at all.
- UAnimationSprite.TAnimationSprite.Update: advances its animation by specified time, and updates its view if neccessary. If a timer didn't update that sprite, its view will remain blank.
- UButton.TButton.LoadAnimationSet: loads certain animations from package system, and assignes currently needed one to its own sprite. Though, if that sprite is never updated, the animation will never be shown.
- UClientWindow.TClientWindow.OnCreate: where the program initializes, and some object are created for debug. That includes one poor button. Which didn't want to show itself.
So, I fixed that condition in the iterator, and the button appeared. Yay!
Hey, I thought that I don't need to announce my tumblr posts at this topic.
Seems like someone didn't get who I was talking about here:
That must be easy even for guys like 風_繊指 the Wind of Slender Womans’ Fingers (wat?). :3
-
That must be easy even for guys like 風_繊指 the Wind of Slender Womans? Fingers (wat?).
Ah I noticed that but I forgot to comment about it xD
Slenderman lol :V
風邪千死 風戦士 plz
That "Core" that you cited, you made it or is it an external library?
And you typed alll that post with a tablet, you are crazy :V
-
Ah I noticed that but I forgot to comment about it xD
Slenderman lol :V
Fingerman. ^o^
風邪千死 風戦士 plz
Dictionaries are surely good~
That "Core" that you cited, you made it or is it an external library?
Do you want its source? :>
And you typed alll that post with a tablet, you are crazy :V
Pff, I've used album orientation to make keys bigger.
Also, if I'll become annoyed by qwerty, I can always change it to japanese-direct-input with mobile layout. :V
Edit: Did I said I am cool enough to write my own game engine? :V
-
The Core rewriting is done for now! Yay! Party hard!
Here is what is already done. (https://www.dropbox.com/s/cewtmvchmjl4irw/Output_Pilot.rar?dl=0) (just a test menu)
Here is source, specially for Kaze_Sensh. :3
-
Hmmm is that Core in Delphi, I think that I read somewhere that you were planning to rewrite it on lua :P
Anyway it looks pretty complete, there are a lot of functions.
-
It would be hard to access WinAPI/DirectX from Lua code.
After all, Lua code cannot be a standalone application, it requires native host which will interact with it, providing useful environment and retrieving expected results.
What will be written in Lua is code that belongs to the game, not to the engine - attack patterns, enemy behaviour, stage sequence etc.
One of DammakuGame.dll's roles, among others, is to be a host for those scripts. Lua itself doesn't contain definitions like "bullet", "sprite" and "spellcard"; what Lua works with are "functions", "tables", "numbers" etc. If you want to work with "attacks" in Lua, you first must clearly describe what it is, and that must be done in the host.
You've misread me a bit, Slender Fingerman. :3
-
Engine development may be really funny.
Today I've written enough code so now, when user clicks "Start" from the main menu, he isn't greeted by empty black screen. He sees a strange animated sprite rotating around window's center. (http://img-fotki.yandex.ru/get/6427/110955323.7/0_b4730_304d654a_orig)
And that's success! Just because it is done from lua scripts (seek for them in "Content" directory, if you want to see sources).
Here (https://www.dropbox.com/s/cewtmvchmjl4irw/Output_Pilot.rar?dl=0)'s this program, if anyone is interested in looking at it with his own eyes.
Though seems like you won't share my fun. :/
Also, the old version with bullets and enemies from the first post still lies there, lol.
-
Lua scripting goes on (you may see the scripts here (https://www.dropbox.com/sh/8o37uletduuvozh/Njl-oPVARl/Content)), now I finally managed to get to danmaku logic, though the functionality of old version is still not reached.
Most of already written code was done to suit not only shmups, but most general sprite-based 2D game types. Particularly, this code may also be adapted to RTS, or similar thing; and I even have some ideas of it.
Probably I will put most time to danmaku, though, I can give you current version of the engine with needed instructions, so you may implement another sort of game. The engine itself is still pretty raw, but its modules' interfaces probably won't change much, so new versions won't render old scripts incompatible.
So, as the project became not just danmaku engine, I've changed the title a bit.
Also, don't you think I should create my own development circle consisting of one man and go drink beer for future inspiration? I particularly like the name "Hold Harmony Sacred", it sounds cool, it belongs to my waifu and clearly states where the circle's legs grow from. :V
-
May I join in the discussion?
I plan to make final year project for game with this engine. Unfortunately, Lua is very new to me.
I hope the this engine would be friendly to me. (Because this is my first time, ppp-please be gently to me! O-ookay?? :blush:)
-
May I join in the discussion?
Of course you may.
I plan to make final year project for game with this engine. Unfortunately, Lua is very new to me.
I hope the this engine would be friendly to me.
I think, this application is less user-friendly than many more popular ones, e. g. Unity or GameMaker. Let's start with a fact that you should know at least basics of programming, since most of game behaviour is expected to be described in scripts, including complex visuals, level structure (danmaku stages are more time-based than space-based, so it's natural to describe them in code rather than in visible layout) etc.
Many aspects are taken from UnrealEngine, e. g. concept of actors and its components, though I wonder if its UnrealScript is even less user-friendly than scripts here.
(Because this is my first time, ppp-please be gently to me! O-ookay?? :blush:)
I myself am far more gently than my engine. I am an youkai, after all. :3
________
Okay, now you can see some really bullet-full stuff: aggressive TV-copter against main character. Here. (https://www.dropbox.com/s/cewtmvchmjl4irw/Output_Pilot.rar?dl=0)
I guess it is time to return to the Core and do unfinished stuff, like write proper loggers (for boss debugging :{ ) and finally implement proper exception handling.
-
I am only first year degree student. I am only capable to object oriented programming and not learning data structure yet. :(
I don't even use Unity3D and GameMaker, at worst, not even cannot to make my own maps and conditioning Lua for Warcraft 3. (I will learn from my friend after this)
When I try move through the your Danmagine V1.2 files via Notepad, I cannot tell how the library linked up to another file so it is my negligence I am afraid. ???
Since there is too many question to ask when I need to compare of other doujin game to this engine and how to make exactly one doujin game, I need to catch a breath there and try algorithm my intention to make one.
Atleast, if someone came up with script where we can try play two stages as a template with character sprite during conversation, character conversation box, character sprite animation, I would like to trace the code if allowed.
-
I am only first year degree student. I am only capable to object oriented programming and not learning data structure yet. :(
Data structure? What data structure? (http://img-fotki.yandex.ru/get/6610/110955323.6/0_a5dc7_84ae66c6_orig)
I don't even use Unity3D and GameMaker, at worst, not even cannot to make my own maps and conditioning Lua for Warcraft 3. (I will learn from my friend after this)
This is bad. :/
When I try move through the your Danmagine V1.2 files via Notepad, I cannot tell how the library linked up to another file so it is my negligence I am afraid. ???
.dll libraries are sort of back-end, and are likely to be not of your any interest, at least because you won't get any useful information.
.lua files, on the other end, contain higher level code. It is splitted in several "packages", each of which describe its own level of objects:
- Engine contain implementations of basic entities, such as Class (an entity which implements some principles of OOP), Actor (game entity, anything that exists in game world), SpriteComponent (an attachable component which shown Actor on screen), UserInputHandler (part of gameplay object dealing with all user input, including keyboard events) and others.
- DammakuGame contains code which describes common rules of danmaku. It introduces Player (actor representing protagonist and controlled by actual player), Bullet (danmaku bullet), Enemy and others.
- Game contains resources, specific to one particular shmup. Currently it contains just simple dueld between a generic player and flying TV box.
All this data is placed in "Content" folder, every package has its own folder.
Client application runs some predefined scripts, in this order:
- some nearly internal code,
- Engine.Main,
- DammakuGame.Main,
- Game.Players.0.Main (currently does nothing),
- Game.MainStage.
All scripts are loaded from .pkg files found in Output directory, which also contai executables themselves. Those packages are built by "Packer.exe", with their structure determined by .tpkg files. E. g. DammakuGame's structure is described in Content\DammakuGame\Index.pkg, which lists all first-level items along with two sub-packages. You may wath "PackGame.bat" to see how the program is called.
If you want to change game's content files, you must not forget to rebuild changed package, since the application doesn't directly use files from "Content" folder, instead, it uses .pkg files lying in the sam folder with binaries.
Since there is too many question to ask when I need to compare of other doujin game to this engine and how to make exactly one doujin game, I need to catch a breath there and try algorithm my intention to make one.
...As I said, my program is not a good choice for beginners.
two stages... conversation... conversation box... character sprite animation...
Oh, wait, wait, not that fast, I need to implement those things first: probably nobody except for me will write appropriate files, among those who can, and it takes time.
-
* 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.
-
* 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.
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. :D
-
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. :D
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. -_-
-
Datmaku.
The page cannot be found, either.
PS, your english is really good :derp:
-
The page cannot be found, either.
Eh?
PS, your english is really good :derp:
:yukkuri:
-
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 (http://msdn.microsoft.com/en-us/library/windows/desktop/ms686358(v=vs.85).aspx)" 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:
-
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 (https://www.dropbox.com/s/auy7weashldzct2/2015-02-27%20output.zip?dl=0).
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 (http://i.imgur.com/7IuRsvb.png); 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.
-
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.
-
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.
________
(http://i.imgur.com/U6QGg9bl.png) (http://i.imgur.com/U6QGg9b.png)
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 (https://www.dropbox.com/s/ljeege3upikg0un/2015-02-28%20output.zip?dl=0).
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.
-
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 (https://msdn.microsoft.com/en-us/library/windows/desktop/bb172617%28v=vs.85%29.aspx).
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
-
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:
(http://i.imgur.com/tKMlAuu.png)
And here's the archive. (https://www.dropbox.com/s/m2tu18jby893c3l/2015-03-13%20output.zip?dl=0) 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.
-
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. (https://www.dropbox.com/s/kq36uns9tj5g6sh/2015-03-16%20output.zip?dl=0)
Look at that sexy plates oh yeah (http://i.imgur.com/v1qZaUy.png)
-
I find pushing some silver-ish buttons and looking how the text below changes oddly satisfying. (https://www.dropbox.com/s/6g7yfvmojfqf6b2/2015-04-07%20output.zip?dl=0)
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.
-
Do you remember me, RaNGE? I guess you don't, but that's okay.
Just dropping there to say I have a GitHub rep (https://github.com/delfigamer/mist) 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.
-
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" (https://www.dropbox.com/s/xtwmvmqpovq08hn/2015-11-07%20output.zip?dl=0). Unpack, run "client-win64", click on the screen many times, enjoy.
-
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.
-
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.
-
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.
-
Strange, on my notebook it runs only at ~200FPS when plugged and ~100FPS otherwise. Maybe you're giving me the second number?
(http://i.imgur.com/4mIyvx2.png)
-
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.