A-Engine Progress Thread [Beta 1.0]

A-Engine Progress Thread [Beta 1.0]

Postby A-Man » June 2nd, 2015, 5:06 pm

It has been long since I last posted any A-Engine progress, and I thought I should post something just to let you guys know I am working on this. Here are some important updates from the top of my head, in brief, starting from what may concern you all the most:

-No more magic numbers. Constants. If anyone has read any of my old posts regarding the A-Engine, they'd be aware of "4321"; a number which usually means nothing and is often used to disable a tag. This has often looked weird and hindered readability when writing long logical expressions. Now, you simply type "NONE" in its place, and suddenly, it's all making sense. In other words, no more "4321". It's now "NONE" and is meant to be typed like that. In additions there are 3 more constants to make things more readable, "MATH_PI" (3.141..), "TRUE" (1) and "FALSE" (0).

-Re-written the pair of frame components which handled collision detection (set_rect[] and set_bdy[]). Now called set_culpritbox[] and set_victimbox[]:
Prototypes:
Code: [Select all] [Expand/Collapse]
set_cultpritbox[
                   x= y= z= w= h= d= goto_when_success= damage= x_impact= y_impact= z_impact= hit_frequency=
                   effect= strength= knock= victim_goto= success_victim_goto= x_victim= y_victim= z_victim=
                   hit_density= flags= set_reg= set_victim_reg= remote_id= fetch_victim_data= x_y_z_effect_translate=
                   set_obj_reg= success_set_reg= success_set_obj_reg= success_set_victim_reg= success_fetch_victim_data=
                  ]
set_victimbox[
                 x= y= z= w= h= d= when_hit= defend= flags= resistivity= inertia= budged_dp= set_reg=
                 set_culprit_reg= set_object_reg= fetch_culprit_data= broken_dp= broken= budged= budged_resistivity=
                 budged_inertia= absorb_damage= absorb_strength= absorb_knock= absorb_x_impact=
                 absorb_y_impact= absorb_z_impact= penetrated_dp= defend_inertia= defend_resistivity= falling=
                 knocked= in_pain=
                 ]
GeSHi © Codebox Plus

While this might not be very cool to those of you whom came from an LF2 modding background , I had to do this to help making things more self-explanatory for everyone. The plan for the future is to have different variations of set_culpritXXX and set_victimXXX where XXX can be "box" for rectangular hitboxes, "point" for point hit"boxes", "circle" for circular hit"boxes", and so on.. In addition to the rename, I've added a whole bunch of new tags that adds lots of what you can do with them. Damage and defending states now can be handled in a much flexible way, although that required changing how "dp" (defend points) and "kp" (knock points) work a little bit.

-New pair of frame components: set_catchbox[] and set_caughtpoint[]:
Prototypes:
Code: [Select all] [Expand/Collapse]
set_catchbox[
             |THROWFRONT|FACESELF|FACEAWAY|THROWBACK|
                 id= x= y= z= w= h= d= x_caught= y_caught= z_caught= success= catch_period=
                 grip= damage= thrown_x_vel= thrown_y_vel= thrown_z_vel= state_caught_goto=
                 front_caught_goto= back_caught_goto= condition= flags= set_reg= set_object_reg=
                 set_victim_reg= fetch_victim_reg=
               ]
set_caughtpoint[
                    |SLIP|
                    x= y= z= condition= flags= set_reg= set_object_reg= set_culprit_reg=
                    fetch_culprit_data= escape= thrown=
                    ]
GeSHi © Codebox Plus

For doing grab attacks and generally anything where your goal is to control other object(s) on the screen (could be a pickable weapon or a vehicle or stuff I haven't thought of). And yes, you can use it to grab more than one targets at a time.

-Perfected expressions:
Finally got around fixing some bugs with how the engine parses and evaluates expressions. And now that the engine was capable of doing lots of calculations that makes a chasing ball, I believe I've finally made it perfect!
Here is a frame of a ball that chases only to the front, and limiting its movement to a max of 25 degrees to any of the directions, implemented in pure A-Script using set_reg= tags and expressions :
Code: [Select all] [Expand/Collapse]
[f=0] #Chasing Energy Ball 1
# Get on-screen id of nearest object which id's not 500 and not of your team
set_reg=$t$, &get_nearest_obj{@id@==500 && @team@ != @this_team@}

# Store the difference in x/y/z positions
set_reg=$x$, &fetch_object_data{$t$, @x_position@} - @x_position@
set_reg=$y$, &fetch_object_data{$t$, @y_position@} - (@y_position@ + 30)
set_reg=$z$, &fetch_object_data{$t$, @z_position@} - @z_position@

# Cancel the whole thing if you're not facing the correct direction
set_reg=$x$, ~(@facing@ == 0 && $x$ > 0) || (@facing@ == 1 && $x$ < 0) ? $x$ : NONE;

# Calculate the x and the y angles from the target
set_reg=$a$, ~$x$ == NONE ? NONE : &atan{$y$/$x$};
set_reg=$b$, ~$x$ == NONE ? NONE : &atan{$z$/$x$};

# Limit the max angle to 25
set_reg=$a$, ~$a$ != NONE && $a$ > 25 ? 25 : $a$;
set_reg=$a$, ~$a$ != NONE && $a$ < -25 ? -25 : $a$;

set_reg=$b$, ~$b$ != NONE && $b$ > 25 ? 25 : $b$;
set_reg=$b$, ~$b$ != NONE && $b$ < -25 ? -25 : $b$;

# Calculate velocities according to the angles. But if no one is in front of you,
# get random offsets for velocity
set_reg=$y$, ~$a$ == NONE ? &randint{-2, 2} : ~@facing@ == 0? &sin{$a$} : -&sin{$a$}; * 15;
set_reg=$z$, ~$b$ == NONE ? &randint{-2, 2} : ~@facing@ == 0? &sin{$b$} : -&sin{$b$}; * 15;
set_reg=$x$, ~$x$ == NONE ? 13 : &cos{$a$} * 15;

img=0 center=56,24 delay=2 x_vel=$x$ y_vel=$y$ z_vel=$z$
set_transformation[center=56,24 x_scale_factor=$s$ y_scale_factor=$s$]
[/f]
GeSHi © Codebox Plus

All of this was a great test that proved expressions work wonderfully, but at the same time, writing up all this just to have the ball chasing someone was a bit of an over-work. For that reason, I worked on a new frame component "track_target[]" which provided tags that does this for you in a line or two.

-New frame component: track_target[]:
Prototype
Code: [Select all] [Expand/Collapse]
track_target[
                 |FACEFORWARD|FACEBACKWARD|
                 target_id= x_acc= y_acc= z_acc= r_acc= max_x_vel= max_y_vel= max_z_vel= max_r_vel= condition=
                 fetch_target_data= set_obj_reg= set_reg= set_target_reg= x_vel= y_vel= z_vel= x_y_z_offset= max_xz_angle=
                 max_xy_angle= store_xz_angle= store_xy_angle=
]
GeSHi © Codebox Plus

I am not going to explain how that works in detail, since everything will be explained in the documentation, but what you use it for is tracking a target. You will mostly find this useful when coding say a chasing energy ball, or a targeting system perhaps.

-Main loop's Time Blocks:
For those who don't know what a main loop in the A-Engine is, it basically is a block of tags surrounded by "{main_loop}{/main_loop}". These tags are to be run in every frame. You can use "set_reg =", "add_hp =", "add_sp =" and other tags that has to do with points, in addition to the recent addition of "call_object[]" and "call_sound[]" frame components which allow you to spawn either an object or play a sound in every frame iteration. You usually would use a main loop when you'd want to set a timer or spawn objects, say sweat particles, every frame period regardless of the frame you're in. You may as well now use it in stage files to do things like spawning lightnings or meteors. Time blocks allow you to set a time interval where the tags written in its block would run:
Code: [Select all] [Expand/Collapse]
{main_loop}
add_hp = 10; #add 10 Health points every frame unit of time.
:30; #a time block; every tag beneath would run only once every 30 frames
add_hp = 20; #add 20 HP every 30 frames
:120; #another time block
#..etc..etc 
{/main_loop}
GeSHi © Codebox Plus


-Dividing your character/object into multiple files:
The "#import[filename.a];" in-file tag will import and replace itself with the content of the file in between the [] when the file is loaded. This allows you to divide your files and helps with readability:
http://i.imgur.com/A1fBloP.png (only template/main.a file is loaded, and it imports the rest)
You may as well place the assets and everything that has to do with your character in its own folder.


-Now for what's being focused on currently:
.Reworking the stage (BG) files. Adding more tags and features that makes creating stages much more flexible. Layers won't have an id anymore, and are now divided into [fgl] and [bgl] (foreground layers that are rendered to the front of objects and background layers that are rendered at the back). New tags that has to do with automatically generating stage elements and bgs of infinite (or very huge) boundaries.
.Started working on the A-Coder; A simple editor in C++ being written with the wxWidgets libraries. Supports auto-completion and syntax highlighting that helps with faster development.

-A word on the release:
It's getting close. If you've read that post in the chit-chat thread, then you probably understand the gravity of the situation where I am. I have been working really hard with mostly all the time I've got, and I'm glad to say everything is going smooth and steady (but slow =P). I will do my best to keep on updating this thread, even if with no much details.

Few decisions I've made regarding the first A-Engine release (Beta 1.0):

.No platform objects: While the A-Engine has promised to have that feature early, I am sorry to say it won't make it to the first A-Engine release. I am planning to use "Box2D", and amazing physics library that is capable of doing mechanical physics to a huge degree of accuracy and in a very optimized manner. You're free to use the current platforms functionality within the "set_culpritrect[]" frame component, but beware as it will be completely replaced later with something new and much more robust in the future.

.Shadows: You all saw how OPAE makes use of these cool pre-rendered shadows? I am sorry to say there is a chance (even though it might still not happen) that I am going to keep it as simple as a circular shadow for the first A-Engine release, and here is why: They're overly simple direct projections of the sprites as it becomes evident the moment you stand on a platform. In the future, I plan to make allow loading 3D-models for buildings or anything with a remarkable size in the z-axis. With that, shadows which can blend and turn and twist according to its surroundings will be possible to do, and I really don't want to re-work the shadows in the future now that I have a clear vision for how I would like them to be.

.No custom AI: Yes, I know, this really sucks, but it's all for the sake of getting a first build to work with. The plan for the future is to allow writing up AI in 2 different ways:
1-Using a real scripting language. Considering Python and Angel Script (for all of those who've came from the LF2 community and have already gotten used to Angel Script): This option will allow full control to what your AI will be able to do.
2-Using a simplified fixed "pipeline" for the beginners: Very simple AI written in A-Script. It will probably involve simple tags that defines conditions and corresponding key-combinations.

.VS mode only: Well.. Yes.. VS MODE ONLY. I can justify: At first, the plan was to get fixed common modes (VS mode, stage mode, battle mode, story mode) that can be mapped to different game mode options in the menu. But then I thought it might be better to just give the developers the freedom to set rules for any mode they'd want to code. Time battles, DBZ's Tenkaichi Budokai tournament rules where players can lose if they're out of the ring, etc..etc should all be possible to code with "mode logic" a-files. The following is an example pseudo-code that shows how I am planning to have these work (an example of a timed mode and Harry Potter's "Squiddish" game mode):
http://pastebin.com/bn6W7xwk
Implementing that would take time to make it to the first release, however, I promise to make it my first priority in the next release.

.ENOUGH with optimizations, for now, for the sake of the release: I have got to admit the A-Engine is pretty slow currently. The engine can begin to hiccup at around 50 objects on the screen on some computers. The reason behind that can be summed up in the following 2 reasons:
1-Expressions: In order to be able to do all the awesome stuff with the registers, functions and variables, the values of the tags had to be stored in "string" variables. These are quite expensive to operate with, especially that what I am doing is effectively creating 1000s of new strings every frame as a result of parsing and converting them to other appropriate types after evaluation. A solution to this problem became clear the moment I adopted C++11 and learnt about the new "auto" identifier. Implementing the solution is very straightforward but time consuming which is why I wanted to leave this for later. Turned out that can't work.
2-Collision detection: is pretty darn slow. I've considered, and in fact already implemented a Quad-Trees based solution for this, but I came across several conflicts with other tags that requires lots of tuning I will be doing later. For that, I had reverted back to the old nested looping ways until then.

Finally, I will do my best to try and post here every now and then. Questions or suggestions will be hopefully answered and considered.
Image
User avatar
A-Man
Infamous Pirate
 
Posts: 401
Joined: March 31st, 2015, 11:40 am

Re: A-Engine Progress Thread [Beta 1.0]

Postby Dragon5 » June 2nd, 2015, 6:33 pm

I would suggest calling the boxes hit and hurt instead of culprit and victim. not only they are easier to type, the words are more universal. It may sound confusing to those unfamiliar with coding but the difference is simple: there's the area you hit with, and the area you get hurt from.

I'm fine with most of these cuts right now (VS mode is all I ever need). The AI is probably the biggest one though. Hopefully the future optimizations won't affect the new code too much.
Just stay calm for now. We will do it when the time comes~
User avatar
Dragon5
Pirate Subordinate
 
Posts: 46
Joined: April 5th, 2015, 1:50 am

Re: A-Engine Progress Thread [Beta 1.0]

Postby Rhino.Freak » June 3rd, 2015, 3:54 am

Awesome. I do agree with Dragon5 with renaming the culprit and victim stuff, it sounds a bit weird for me.
A simple set_attackbox and set_bodybox would be quite explanatory..

But can we keep shadows as it is for now? I mean is there really a need to get rid of it and have circular ones?
Image
User avatar
Rhino.Freak
Site Admin
 
Posts: 533
Joined: March 31st, 2015, 12:09 pm
Location: Somewhea~

Re: A-Engine Progress Thread [Beta 1.0]

Postby A-Man » June 3rd, 2015, 6:46 pm

Dragon5 wrote:I would suggest calling the boxes hit and hurt instead of culprit and victim. not only they are easier to type, the words are more universal. It may sound confusing to those unfamiliar with coding but the difference is simple: there's the area you hit with, and the area you get hurt from.

Rhino.Freak wrote:Awesome. I do agree with Dragon5 with renaming the culprit and victim stuff, it sounds a bit weird for me.
A simple set_attackbox and set_bodybox would be quite explanatory..

Sounds cool then. What about the tags names then? Should they be changed i.e:
"victim_goto", "success_victim_goto" for the hitbox and "set_culprit_reg", "fetch_culprit_data" for the hurtbox
vs
"hurt_goto", "success_hurt_goto" for the hitbox and "set_hit_reg", "fetch_hit_data" for the hurtbox
Does the latter look clear?

The reason I don't want to get the keyword "attack" into all this is that "hitboxes" are not necessarily attacks. They are interaction areas which the purpose from might be fetching data or sticking to that target or anything.

I'm fine with most of these cuts right now (VS mode is all I ever need). The AI is probably the biggest one though. Hopefully the future optimizations won't affect the new code too much.

I understand the issues with the AI, and I will try to come up with a quick solution that will do until then. Perhaps, a mid ranged AI that randomly activates any combination it comes through.

The future optimizations shouldn't change anything with how this version will come up. This is why I am trying to finalize with the naming conventions once and for all now. I will probably revise them all here with you guys before the release.

Regarding naming conventions, I have been wanting to change "HP" to "LP" (life points). Since that can and might be used for stuff ranging from energy balls to destructible objects, "life points" would be a generic name that covers all that. In addition, I've had a thought of changing the key names, c/h<a> (attack), c/h<j>, c/h<d> and c/h<s> into numbers instead c/h<0..1..2..3..etc>, since there isn't really any privileges/differences between any of the four buttons (thoughts?)

But can we keep shadows as it is for now? I mean is there really a need to get rid of it and have circular ones?

I had to rewrite everything graphics related when I switched over to OpenGL 3.+ , but I can redo them if you want it this much (it is fairly simple to do with the new stuff, now that I think about it).
Image
User avatar
A-Man
Infamous Pirate
 
Posts: 401
Joined: March 31st, 2015, 11:40 am

Re: A-Engine Progress Thread [Beta 1.0]

Postby Dragon5 » June 4th, 2015, 7:16 pm

The AI isn't that important right now, so don't try to rush it out. Anyway I'd like the consistency for hit and hurt as well.

About the buttons. I don't mind changing them to something more universal. Numbers should work better as directions already use letters.
Just stay calm for now. We will do it when the time comes~
User avatar
Dragon5
Pirate Subordinate
 
Posts: 46
Joined: April 5th, 2015, 1:50 am

Re: A-Engine Progress Thread [Beta 1.0]

Postby Rhino.Freak » June 8th, 2015, 10:57 am

I don't mind the changes with the key inputs. But I think letter were self explanatory, we need to remember what's what in case of numbers.. no issues tho since I can understand that the 4th and 5th button will be used differently in different games..

I don't know about LP. HP is much more widely known and accepted standard in all kind of games. Health does correspond to Life anyway so I don't really like that change in particular.

Hurt goto and success hurt goto sounds good to me. Very readable.

Yay for shadows XD

And will the fifth button support be available for the 1st release?
Image
User avatar
Rhino.Freak
Site Admin
 
Posts: 533
Joined: March 31st, 2015, 12:09 pm
Location: Somewhea~

Re: A-Engine Progress Thread [Beta 1.0]

Postby A-Man » June 8th, 2015, 7:16 pm

Rhino.Freak wrote:I don't mind the changes with the key inputs. But I think letter were self explanatory, we need to remember what's what in case of numbers.. no issues tho since I can understand that the 4th and 5th button will be used differently in different games..

They weren't self-explanatory actually, since you could assign c<a> for defending or jumping, and it would all work perfect. It was more of a built-in label that meant nothing.
Here are some advantages we get if we use numbers instead:
-We can have as many buttons as we ever need without worrying about repetition of the labels. c/h<0> c/h<1> c/h<2> ..etc.
-Directional buttons would be more readable: Especially c/h<d_a> and c/h<u_a> which represented Down (arrow) and Up (arrow). They would now simply be named c<d> for down and c<u> for up since we we won't have c<d> for "defend' anymore.

I will see if I can allow mapping these numbers to labels in the "system.a" file.


Rhino.Freak wrote:I don't know about LP. HP is much more widely known and accepted standard in all kind of games. Health does correspond to Life anyway so I don't really like that change in particular.

Hurt goto and success hurt goto sounds good to me. Very readable.

Yay for shadows XD

And will the fifth button support be available for the 1st release?

I've seen LP used in games before. Plus "Life points" is a more generic name that can perfectly label anything. You can say the life-points of an energy ball or life-points of a particle engine. HP is restricted to characters though, and is quite misleading too (one can assume Health has to do with Poison, Sickness..etc effects).

Right!

I will probably just add 10 buttons (from 0 to 9) if we go with numbers. There is a chance I am getting mouse inputs too for some shooter game I am planning.
Image
User avatar
A-Man
Infamous Pirate
 
Posts: 401
Joined: March 31st, 2015, 11:40 am

Re: A-Engine Progress Thread [Beta 1.0]

Postby Dragon5 » June 10th, 2015, 6:18 pm

Keep it numbers They are used in fighting games as a universal way of explaining buttons. 123456 in games like Street Fighter is LMH for punches then kicks. 1234 in games like Tekken and Mortal Kombat means left then right for punches then kicks. It's not like buttons are hard-coded into the game now like LF2 was anyway.
Just stay calm for now. We will do it when the time comes~
User avatar
Dragon5
Pirate Subordinate
 
Posts: 46
Joined: April 5th, 2015, 1:50 am

Re: A-Engine Progress Thread [Beta 1.0]

Postby A-Man » September 10th, 2015, 8:52 am

So for those who've been following and haven't lost all hope yet, know that I am finally back actively working on the A-Engine! I've recently got some of those to power up my computer, but I got busy with few other projects. Starting few days ago, I've got back working on the A-Engine, and this time, I'm planning to completely focus on it until I release something. Also, it might be of your interest to know that http://www.a-superlab.com will be up sometime next week including a whole A-Engine section with a devblog in which I will be posting frequent updates on pretty much every single thing I work on.
Stay tuned!
Image
User avatar
A-Man
Infamous Pirate
 
Posts: 401
Joined: March 31st, 2015, 11:40 am

Re: A-Engine Progress Thread [Beta 1.0]

Postby Dragon5 » September 11th, 2015, 1:06 am

Can't believe it's been three months. Can't say for certain whether I'll be able to stick around, but I'll definitely try.
Just stay calm for now. We will do it when the time comes~
User avatar
Dragon5
Pirate Subordinate
 
Posts: 46
Joined: April 5th, 2015, 1:50 am

Re: A-Engine Progress Thread [Beta 1.0]

Postby A-Man » September 11th, 2015, 6:24 am

Yes, things got pretty rough for me, sorry :\. But for all the contribution you've made by feedback you've given, I certainly hope you stay.
Image
User avatar
A-Man
Infamous Pirate
 
Posts: 401
Joined: March 31st, 2015, 11:40 am

Re: A-Engine Progress Thread [Beta 1.0]

Postby Dragon5 » September 12th, 2015, 6:52 pm

I'm just saying I can't make a promise because I don't know what life will hit me with. College life is picking up. That's all
Just stay calm for now. We will do it when the time comes~
User avatar
Dragon5
Pirate Subordinate
 
Posts: 46
Joined: April 5th, 2015, 1:50 am

Re: A-Engine Progress Thread [Beta 1.0]

Postby A-Man » September 27th, 2015, 10:11 am

The website is up with new updates on the A-Engine! Check the A-Engine's Dev Blog section for more info. I will be posting there more often, and maybe let the forum be for big updates.
Image
User avatar
A-Man
Infamous Pirate
 
Posts: 401
Joined: March 31st, 2015, 11:40 am

Re: A-Engine Progress Thread [Beta 1.0]

Postby A-Man » October 25th, 2015, 1:40 pm

I thank all of you A-ngineers for your patience so far, and I'd like to inform you guys that the graphics pipeline code is going through a rewrite for the sake of incorporating awesome new techniques I learnt in the last period! Stay tuned for the next striking update.
Image
User avatar
A-Man
Infamous Pirate
 
Posts: 401
Joined: March 31st, 2015, 11:40 am

Re: A-Engine Progress Thread [Beta 1.0]

Postby A-Man » November 16th, 2015, 11:44 am

Hello, I am still alive :P. So a bit over a month since I last posted a log or anything of that sort, but I'd like to know that I haven't taken a single day off from working on the A-Engine. The graphics portion has been completely rewritten and can now do the following:

-Load and display sprite sheets (old).
-Load and display complete 3D models with textures and lighting, no animation yet, however. Probably not going to be in for this release at least.
-Producing realistic shadows according to a light source (using shadow maps). For starters, you will only be able to have 1 light source. Support to multiple light sources will not be added in the coming version.
-Able to load external GLSL shaders and ability to create your own graphics tags that works with custom shaders you can write (you can bind a tag name to a uniform you add. Don't worry if you don't understand, I will write a tutorial eventually).
-Cameras have been greatly simplified from the design plan I posted in the last blog post. I found defining a dynamic camera that works with setting speed, acceleration ..etc to be very difficult to get right and very prone to malfunctioning. So instead, I tried an approach that uses "weighed positions"; much more intuitive, much less tags to set up and easier to work with.

What I still have in mind:
-Height maps: Easy, but useless now as rigid body physics isn't done yet (and won't be done in the coming version, for the sake of getting something out fast).
-Getting cascaded shadow maps for directional light (important for quality of shadows to be consistent, but not a priority if the shadow map size is big enough).
-Adding the A-script layer which is necessary for coders to use all these features at all.

All of that will be explained in detail in the next blog post which is scheduled for next week (Sunday, hopefully).
Image
User avatar
A-Man
Infamous Pirate
 
Posts: 401
Joined: March 31st, 2015, 11:40 am

Re: A-Engine Progress Thread [Beta 1.0]

Postby A-Man » March 15th, 2016, 12:41 pm

Watch out for a new blog post next week. There's a loot I want to talk about =) Sorry for not keeping you guys updated, but trust me when I say I had a good reason not to.

Edit: New post is up http://www.a-superlab.com/2016/03/15/a- ... st-bodges/

Sorry if it isn’t what you expected, but that was a part I felt I had to write about. Next week's will be more about the new features and updates the A-Engine has received. Thanks for reading!
Image
User avatar
A-Man
Infamous Pirate
 
Posts: 401
Joined: March 31st, 2015, 11:40 am

Re: A-Engine Progress Thread [Beta 1.0]

Postby Rhino.Freak » March 15th, 2016, 1:29 pm

Very cool stuff.
Even though it's nothing to get excited about basically but that organized structure looks so good and satisfies the clean code loving ghost inside me.
So is that all the stuff remaining? The PhysicsManager, and other 2?
Image
User avatar
Rhino.Freak
Site Admin
 
Posts: 533
Joined: March 31st, 2015, 12:09 pm
Location: Somewhea~

Re: A-Engine Progress Thread [Beta 1.0]

Postby A-Man » March 15th, 2016, 2:27 pm

lol it does look nice. Before I answer your question on what's remaining, I should point out that these classes are more of interfacing to underlying smaller more specific classes in a big hierarchy tree (root being the AEngine class). These small components greatly differ in complexity, as you may find that what's under the Graphics component took me twice the time to implement compared to the ScopeManager class and what's under it. The FileManager class and its components however did take much more time as I followed an approach I've never done before with it. The InputManager class took me very little time to prepare, and the ObjectManager sub-tree, while being the lengthiest, doesn't seem like it will be taking me too long (quite straight forward, so far). The SoundManager I can tell may take as little time as the InputManager to implement if I work with SDL_Mixer. But as I plan to use OpenAL for it (which looks very similar to the OpenGL I'm familiar with), things might take a little longer than with SDL_Mixer as OpenAL involves distance/diffraction..etc calculation and sound filters, all which would be nice to have in the A-Engine. The plan with the PhysicsManager is to just get simple collision detection for now and improve it later on, so that should be breeze to do. The NetworkManager is for online related stuff which I really don't have much experience with to tell you about :P.

But yes, the plan is to initially release on github as soon as I can. From there I will be uploading builds from time to time and commit the updates for everyone to immediately access them when they're ready.
Image
User avatar
A-Man
Infamous Pirate
 
Posts: 401
Joined: March 31st, 2015, 11:40 am

Re: A-Engine Progress Thread [Beta 1.0]

Postby A-Man » March 28th, 2016, 5:27 pm

Image
User avatar
A-Man
Infamous Pirate
 
Posts: 401
Joined: March 31st, 2015, 11:40 am


Return to Releases and Update Logs

Who is online

Users browsing this forum: No registered users and 1 guest