Thread Rating:
  • 5 Vote(s) - 3.8 Average
  • 1
  • 2
  • 3
  • 4
  • 5
The A-Engine: A new Beat 'em Up game engine
#61
I am sorry, but I can't give a date as I really don't know myself. I recently started a devblog which you can check in my signature, and I've been posting there in detail regarding what I'm working at fairly often. Once I am close enough, I am sure it will become clear.
[Image: signature.png]
A-Engine: A new beat em up game engine inspired by LF2. Coming soon

A-Engine Dev Blog - Update #8: Timeout

Reply
Thanks given by: Hate
#62


Edit: An example that shows how shaders can change how your graphics look:
[Image: QRTsttU.png]
[Image: signature.png]
A-Engine: A new beat em up game engine inspired by LF2. Coming soon

A-Engine Dev Blog - Update #8: Timeout

Reply
#63
[Image: signature.png]
A-Engine: A new beat em up game engine inspired by LF2. Coming soon

A-Engine Dev Blog - Update #8: Timeout

Reply
Thanks given by: Rhino.Freak
#64
Here are few things I'm puzzled by:
- How does your shader implementation blend with the engine? How can someone use uniforms and such in glsl without altering the source code? Is this going to be easy? Do you have a default shader program hardcoded in engine?
- Do you really think blending 3D models and 2D sprites going to feel natural? Isn't it unnecessary complication?
- Do you have any idea how hard 3D modeling is?
- You seem to be trying to finish everything at once. Why don't you finish a small subset of engine and make it playable as soon as possible so people can start experimenting faster and you can incrementally develop it as time goes by?
- Still not using source control?
- A-Engine seems like it's going to be way too complicated. Is there any plan on simplifying it? (it almost requires fair programming skills for anything serious)
- How does your engine handle memory management of your a-scripts?
- Being able to do string processing in a-script seems too dangerous and unnecessary...
- Did you ever thought about using Lua as your script backend (or whatever suits)? Lua is designed embedding in mind and it's known to be the fastest script language (people write nontrivial games with it)
- Do you actually want to make it open source?
- Is this ever going to finish? :D
Ultimately, my constant dissatisfaction with the way things are becomes the driving force behind everything I do.
[Image: sigline.png]
LF2 IDE - Advanced visual data changer featuring instant data loader
LF2 Sprite Sheet Generator - Template based sprite sheet generator based on Gad's method
[Image: sigline.png]
There is no perfect language, but C++ is the worst.
Reply
Thanks given by: A-Man
#65
lol, before I get to answering the questions, I want to say that the A-Engine project has been rebooted (since a while ago).

Quote:How does your shader implementation blend with the engine? How can someone use uniforms and such in glsl without altering the source code? Is this going to be easy?
For the user, setting a uniform is as simple as surrounding it by an ID component and linking it to a tag:
Code:
#version 150

in vec2 textureCoordinates;

uniform sampler2D uTexture1; //first texture; "image = " tag in A-Engine

[TAG_NAME="saturation"] // "saturation = 2"  in .a files will set this value to 2
 uniform float uSaturation;
[/TAG_NAME]

int main()
{
 vec4 pixelColor = texture2D(uTexture1, textureCoordinates); // fetch the pixel color off the texture
 pixelColor = pixelColor * uSaturation;
 gl_FragColor = pixelColor ;
}

varyings/ins/outs I don't expect people to want to change them. But if they do, I'll think of something similar.
Loading shaders is done via the A-Engine data.txt equivalent.
Code:
{shaders}
 [ID=1]
   TEXTURED = "folder/folder/textured.frag"
   LIGHTED = "folder/folder/lighted.frag"
   TEXTURED_LIGHTED = "folder/folder/textured_lighted.frag"
 [/ID]
{/shaders}
3 because:
-First for rendering images ignoring lighting
-Second for rendering models with no textures
-Third for rendering images with lighting

You may leave one or 2 of the 3, and the A-Engine will fall back to a default one for those cases.
Using them is as followed:
Code:
{media}
 {images}
   sheet[DIR = "sheet.png" W = 100 H = 100 ROWS = 10 COLUMNS = 10 SEPERATOR = 3 SHADER = 1 ] # set as default wne you load it
 {/images}
{/media}
[F = 100]
 image = 10 shader = 1 # or you can declare using it for one frame
 xy_center = 39, 79 delay = 3 goto = 101
[/F]


Quote:Do you have a default shader program hardcoded in engine?
There is a default, but it's not hardcoded :P. It wouldn't be a bad idea to write it in the source.

Quote:- Do you really think blending 3D models and 2D sprites going to feel natural? Isn't it unnecessary complication?
It really doesn't in most cases (the screenshots I've provided). But it does look wonderful at times if done right (Paper Mario!); if all models and sprites have same texture detail, and the fov is not very small to help make things flatter with perspective projection. Plus you can still use 3D models with orthographic projection if you want to flatten everything.

But just to show what the A-Engine has to offer anyway. You can keep at 2D-only or 3D-only if you wish.

Quote:- Do you have any idea how hard 3D modeling is?
Not as hard as quality sprites, but they're hard indeed. It's even harder to do game-optimized ones, but I couldn't care less :P. I write an engine that can load 3D models, not a 3D magic modeller.

Quote:- You seem to be trying to finish everything at once. Why don't you finish a small subset of engine and make it playable as soon as possible so people can start experimenting faster and you can incrementally develop it as time goes by?
That has been the goal, and I've reached stages where I could make something playable with it (and I actually did release something playable before, but not under the name "A-Engine"). But yes, really, this is the plan next.

Quote:- Still not using source control?
oops  :( I really plan to. I'll put what I have on GitHub soon.

Quote:- A-Engine seems like it's going to be way too complicated. Is there any plan on simplifying it? (it almost requires fair programming skills for anything serious)
I don't really see where you'd NEED programming skills if you're not into something that can't be done otherwise. An A-Engine character file looks very similar to LF2's. Just like LF2, everything is controlled by frames, and a lot of the tags are analogous (next: and goto=, wait: and delay=, pic: and image=, centerx:, centery: and x_center=, y_center=, dvx: and x_velocity=, opoint: and call_object[], itr: and hit_box[] ..etc). The difference is that you've got various new tags for lots of new stuff, and that tags like LF2's "state:" and "kind:" which gave fixed properties and constraints has been replaced by "switches" and other tags.

Things need to get complicated if you wish to do something complicated too.

Quote:- How does your engine handle memory management of your a-scripts?
"Memory management" is a scary word (phrase), I wouldn't use it to describe what I do XD.
But yes, first, before you make programming-phobic folks here run away, I should mention that a-scripts will very often not be used for things other than AI (and even AI will have a simple optional layer to make a character do simple things). This is one way you can use it:
Code:
<<-use_hp_for_mp
 if (@hp > 100) then
   @hp -= 10
   @mp += 100
 end
use_hp_for_mp

[F=123]
 <<use_hp_for_mp()>> #call script/function
 image = 120 xy_center = 10, 10
[/F]


Another option is to write the script body inside the frame's "<<>>". That would have made the script/function not usable outside the frame, and you wouldn't need to name it. But regardless, you could have also just used the "add_hp=", "add_mp=" tags instead (safer, since you don't need to worry about going over the max hp or something; the tags handle it for you):
    PYTHON-Code:
[F=123]
 image = 120 xy_center = 10, 10 
 add_hp = (@hp > 100) ? 0 : -10 
 add_sp = (@hp > 100) ? 0 : 100
[/F]


But to actually answer your question, I just allocate memory for all variables in the script when its run (in a simple std::vector<AValue<float>>; AValue is the main (dynamic) type), and its freed automatically when the script finishes running. There are other details concerning scoping, but the gist of it is that its just a hierarchy of a vector of pointers from the above vector for every level.

Quote:- Did you ever thought about using Lua as your script backend (or whatever suits)? Lua is designed embedding in mind and it's known to be the fastest script language (people write nontrivial games with it)
I did consider python and Angel Script for a while, but the latter is slow, and the second.. Well, I'm not coming up with an excuse. I'll just say making my own little thing sounded more exciting XP. I'm not much worried about performance, because A-Script does very well I think. I admit I'm guilty for not checking out other options further, and I really could have saved myself some time. But I learnt a lot.

Quote:- Do you actually want to make it open source?
Of course. It'd be nice if you can take a look at it and give me some tips then.

Quote:- Is this ever going to finish? :D
It will. I don't know about "finish" since I plan to actively work on it for a while more afterwards, but it'll be released as something usable soon.
[Image: signature.png]
A-Engine: A new beat em up game engine inspired by LF2. Coming soon

A-Engine Dev Blog - Update #8: Timeout

Reply
Thanks given by: MoragWan , Ariyan
#66
Download link please??
I tried searching A Enging in Google but I didn't go
CLICK the pic to DOWNLOAD
[Image: Zepo.png]
Reply
Thanks given by:




Users browsing this thread: 1 Guest(s)