September 11, 2016 at 5:10 am #3856
This thread is a continuation of my work on the Alien Phoenix framework located here.
I have been working on porting my Monkey-x code to Monkey 2. 🙂 After taking a little break this summer I’m back at it and I have managed to port more or less the core (GUI and other code) of the framework. Below is a screen shot of my progress showing the GUI and mapping systems all working. I still have more code to convert but at this point it is nice to see the core systems of the framework working on Monkey2. This porting or conversion has gone fairly well, as I get used to the Monkey 2 way of getting things done. Porting is a good way to get familiar with a new language and I’m learning just a ton about Monkey2.
I’ll have a video of my progress up soon. 😉
Attachments:September 11, 2016 at 7:21 am #3858
I agree Richard. I ported my framework and two games now to Monkey 2 and sure learned a lot. But, one side effect of this is that you don’t pickup on new language features because you are porting ‘legacy’ code.
Looking good btw!September 11, 2016 at 9:29 am #3861
Looking good btw!
But, one side effect of this is that you don’t pickup on new language features because you are porting ‘legacy’ code.
This, in large part is true, but in my case not entirely. I’ll be perhaps changing some list structures to stacks and perhaps adding in a few other new Monkey 2 features. That said though this frameworks origins are in BlitzMax so much of the frameworks code level interactions will be using objects and properties (class field properties), callable functions and methods and feel familiar to pre-monkey2 coders. The framework does work very well and will fit in with almost anything a Monkey-2 coder is likely to do.
I might have gone a slightly different way on some of the frameworks architecture if I had developed it with Monkey 2 exclusively, but not too much different. As my architecture stands now there is not much I would change really. Use of lambada’s might be one new Monkey 2 feature I would have used for example. Still I am happy using list’s and objects and with a GUI they are very suitable and efficient. There is also plenty to still be added to the framework feature wise and some of the new Monkey 2 features may be added in then (if appropriate, I sometimes see no need to use them…).
@all – Architecture
One such area is an event system which I am open to discussion on. Really, I’m open to any discussion relating to Monkey 2 and this frameworks architecture. Up to now I have been using custom lists to keep track of the state of GUI components for example. I actually prefer using these custom group lists for GUI components (buttons, sliders, list boxes) as all I do is pass along the custom group list on GUI component creation like so.Monkey123456Local mylist:= List<Button>Local generic_button:Buttongeneric_button.New("My Button",x,y,w,h,mylist)'or thisgeneric_button=generic_button.New("My Button",x,y,w,h,mylist)
When I do this the GUI framework will automatically add the object of whatever is created to the included group list. I can then use this custom group list to poll the state or even modify the GUI component directly. So for example I can have a group list of all the user created buttons within a window, iterate through them to check a windows GUI component state and then using the same list/object modify the button if need be. It has proved to be a efficient and easy way to deal with GUI components. It’s also an efficient way to deal with the overhead as when a window is hidden or inactive no list iteration or polling occurs (generally).
I’ve also made it easy to get the property of an object like a window or say a button as well as methods or functions for getting or setting state. For example:Monkey123'Get window 'X' positionLocal my_x:Float=mywindow.xmy_x=mywindow.GetWindowX()
This method for setting or getting state has worked well and when coupled with the above group lists ends up to be a nice way of interacting.
An event system to me seems not to be as efficient, in that, most event systems I’ve encountered seem to log events from many different sources. The coder is still left with iterating through the list of events and the event system itself in my minds eye is not efficient as it records lots of events most of which are not used as polled data. So I’m trying to justify the use of an event system.
I’m pretty happy with the frameworks architecture and there is and only so much of it that can be modified at this point, but I would not mind some feed back on what others might like to see added or if the overall code architecture can be easily fit into their projects. I am happy to explain how this framework works and how to code for it. 😉September 11, 2016 at 10:41 am #3864
Basically it’s only the main window that actually ‘gets’ events.
You then have some form of manager that allocates where (in your app) the events are going.
The best solution here is to track the current gui control and if the mouse is still in it – send it the event. if it’s not in it then you will need to run through each gui control and see if it is the control that wants the event.
Of course some events may be open to more than one control and some events may be directed to the current focussed control.
You will still have to create a manager to handle all of this though.
Games have a lot of cross over with events.
E.G. 1. a mouse click could also be a joystick button click which could also be a return key.
E.G. 2 joystick up/down could also be the same as arrow key up/down
Your manager should be intelligent enough to handle this automatically
The end result is a system whee the user has complete freedom to choose whatever input method they want to use.
The key thing with all of this is 1 Event send ONLY to the main window. you need to decide then what to do with it.
NOTE. MojoX has a primitive manager that will send events to the general relevant control
To finish – an event system is the most efficient system. because that is what is actually gong on behind the scenes. But you need to get your head around it firstSeptember 11, 2016 at 11:21 am #3866
All good stuff, but I’m really discussing the ‘need’ for an event manager as opposed to the design of one. Comparing the method I am using now against an event system. This frameworks GUI system uses no event manager yet functions very nicely and efficiently by use of internal comparative lists where for example management of a button (including state changes) is done on update.
I guess the takeaway here is that I currently use lists of GUI components (custom group lists, see above) that I can poll and modify with a high degree of flexibility and efficiency. I am interested in the arguments for or against such a method when compared to an event system..
I can post some pseudo code that might help explain what I am trying to get across as it might be a little hard to get a good grasp of the method I am using without seeing the framework code. If that would help anyone. 🙂September 11, 2016 at 6:12 pm #3876
You have my permission. 🙂 Let’s keep this going, if it doesn’t distract you too much from actually coding stuff.September 12, 2016 at 6:43 am #3891
Let’s keep this going, if it doesn’t distract you too much from actually coding stuff.
I will break this up probably over several posts as there is a lot to cover. I will start to explain the overall architecture later today/tomorrow and then expand from there. But, before I do, I wanted to explain a little on my history when it comes to GUI’s and my goals for Alien Phoenix.
My first attempt at designing a GUI environment was B-Windows for Blitz 3D (see image below) that was really an experiment in coding a GUI based environment. I say environment as my goal was to fully integrate the GUI with the programming language so that the GUI manages drawing, 3D and other rendering, text and so on. As part of this integration goal I experimented with building a GUI in native code and the result was B-Windows. I really never released this as it was more or less a learning experience, still B-Windows allowed for seamless integration with Blitz 3D and like my current Alien Phoenix project used a window based approach.
So this is not my first attempt at designing a GUI environment and much of what I learned (what to do and what not to do) from B-Windows is being applied to the Alein Phoenix framework. My goal with Alien Phoenix is to allow the Monkey 2 coder to access a rich GUI environment that works as seamlessly as possible with Monkey 2. That allows all of the pertinent or related aspects of Monkey 2 to be managed by the GUI. So modules like mojo are fully supported allowing the GUI to manage drawing, rendering, even primitives like oval. This extends to relevant eventual third party or any native 3D modules. I also want to develop a GUI environment that is flexible and efficient.
In fact efficiency is an overarching design goal. At the moment the Alien Phoenix demo used to make the screen shoot in the first post (way up top) is running with a CPU load of 1% on my AMD Phenom II x4. This is with two GUI windows, one running a list box and tiled image scroll and the other running with my mapping framework. Factor in the CPU load from the map system (which is way efficient) and the GUI is preforming most efficiently. It’s important to note that the GUI is managing and drawing the images, text and GUI components within each window as well as the windows themselves.
Efficiency also caries through to mobile devices or web browsers where it counts the most. One other top tier goal in designing Alien Phoenix is building a GUI environment that can seamlessly work on the PC, mobile and web browser. Reaching this goal requires uber efficiency and flexibility and as many here have already seen (see this Alien Phoenix mobile video) this GUI is making good progress on reaching that goal.
So I could go on and on but I will expand more on this in the next post as well as post some code examples of how a window is created and how to draw to it. I’ll also layout the overall architecture of the GUI and how the GUI interacts with Monkey 2. As I do, I hope that I can explain what I’m upto and my approach well enough so that others can see the value that Alien Phoenix will offer. 😉
Note: I have added B-Windows (source code) as an attachment. If you have Blitz3D kicking around why not check it out. It was done about 12 years ago :O . I compiled it here and it still runs on Windows 7. If you do get an error on compile then change the color depth to 32 in ‘B_Windows_3d_example_window_3d_ex.bb’.
Attachments:September 13, 2016 at 5:10 pm #3923
Today I will explain a bit about the framework flow and component layers that I have functioning at present. Below is a simple block diagram that illustrates this.
So probably the easiest way to explain this is to first describe the basic functions of the component layers listed above.
Base API -This handles (for now) all of the other tasks not seen in the diagram. This includes things like scripting, alert boxes, background screen image or system console. Basically a catchall for the extra bits.
Scheduler – This schedules what needs to be updated and in what order. It handles updating the GUI and Base API.
GUI – The GUI framework layer is pretty self explanatory. It consist of sever layers of components which I’ll describe in the following post. The GUI also handles the final stage drawing or rendering of GUI components, images and 3D rendering. All of the following component layers in this framework will access the GUI layer to draw or render.
Input – This handles inputs from a device like keyboard or mouse.
Physics – The physics layer is entity based. This means that a coder will create a physics object instance and then use that object when accessing the input, weapons and mapping layers.
Weapons – This handles all weapon based entities. This includes entity update and drawing or rendering of the entity.
Map Parts – This manages the base map entities (single instances) which I like to call parts. In the screen shot of the demo (top post) all of the asteroids, base walls and floors are made from map part objects managed by this layer.
Mapping – This is the main mapping system. It uses a tree structure that is composed of many map part references. It also handles most of the collision duties as well as drawing or render of the map part objects.
Collision – As of now this is a simple collection of methods and functions that support the other framework layers.
Hopefully, with the diagram, you can start to get a sense of how the parts of the framework work together. I am going to layout the GUI flow and component layers in the following post much like I’ve done here. This will allow me to then post actual real world code and that should help you get an understanding how to code for the framework from the Monkey 2 API layer.
More tomorrow. 🙂September 13, 2016 at 7:15 pm #3924
Is GUI a poorly chosen name? Because I cannot see why a GUI system is driving or supporting areas like input and weapons….September 13, 2016 at 8:26 pm #3925
The six layers below the GUI (input, weapons and alike) simply reference properties or aspects of the GUI layer. They are essentially independent and other then say using a windows object instance to get something like window width, height and position or drawing to a window, have little interaction with the GUI. The line from the GUI to those six layers is meant to indicate an access pipeline as well as the lines from the Monkey 2 API. The GUI does all the GUI stuff you might expect but also is the final stage in rendering so layers like the six mentioned here are not bound with the GUI, instead, for the most part are sending data that needs to be rendered ala. DrawWindowImage().
Input would also be in the same vein as that layer is responsible for managing specialized inputs. Weapons fire for example or in the case of a mobile device a nav-dish. The input layer will use the physics layer (physics entity), the GUI button layer (explained in next post) and even draw to a window (weapon entity image).
This modular style lets each layer exploit each connected layer as needed. This increases efficiency, flexibility and performance. Something I’ll be able to show in code here soon.September 21, 2016 at 12:10 pm #4044
I’ve been busy fixing bugs and converting code. So, I will continue my explanation of the Alien Phoenix framework here soon. I’ll be continuing that discussion as I have time.
Included are some images of some of the improvements I’ve made to the mapping system and use of a new particle system layer I’m adding to the framework. I am working on my game project Phoenix USC as well as this framework (Alien Phoenix powers Phoenix USC) so the images also include improvements (for Phoenix USC) to background detail and a thrust tail for the ship. I’ll have a new video up soon, after I get the weapons code fully converted to Monkey 2.
I’m hoping the video really shows off what Monkey 2 can do even at this early stage. 😉September 28, 2016 at 4:07 pm #4131
Attached is an image of new ship, particle and weapons effects all running on Monkey 2. I have some additional images here on my Facebook page.
These images show progress of this framework using assets from my PUSC game project. Basically I have written a small demo using the Alien Phoenix framework.
I should have a video up this weekend. 😀
Attachments:September 30, 2016 at 10:49 pm #4188
New video of Alien Phoenix
As promised here is a video of the latest improvements and current state of the Alien Phoenix framework. The demo running here is really just a small demo showing off what Alien Phoenix can do and showing my Phoenix USC (my game project) supporters what is to come.
You can also see a pop-up menu used to select the ships in the demo. It’s made by using a list box. List boxes can be used for menus as well and soon I will be adding a menu layer to the GUI framework using list boxes which are part of a foundational class of GUI components.
This demo was also built with Monkey 2 1.0.7 and looks to be running very well with it. I’ll be adding in lighting and shadows here next and I will be posting a non Phoenix USC demo showing off the Alien Phoenix framework soon. I’ll post a Linux version first and then hopefully a Windows version as well.
Off to code. 😉October 5, 2016 at 7:35 am #4273
Starting to see the light. 🙂
Attachments:October 21, 2016 at 10:40 am #4557
Shadows and light. 🙂 Getting a better grasp of how to best to fit in the new mojo lighting feature.
You must be logged in to reply to this topic.