Alien Phoenix

Monkey Archive Forums/Monkey Projects/Alien Phoenix

Richard Betson(Posted 2015) [#1]


Hi,

As you may know I have developed a 2D game framework for my game project Phoenix USC (www.phoenixusc.com) and I have begun to port over sections of the framework to Monkey-X to get ready for MX2. This time around in porting and development I am going to design a 2D gaming framework which will focus on fast game play with high entity counts, GUI and user interface, world editor and a server and client. I have learned from developing Phoenix USC that the best solution (for me) is to develop a integrated gaming framework I can use to develop other games. So I am going to do just that.

The above video is a test of the GUI, user interface and physics code I have ported and developed to date (for Monkey X). In this redesign I have decided to expand and exploit the GUI systems and layer in a user interface framework that handles the menus and other interfaces. The user interface system now has scripting and all of the background images (mock menu) use it. The script system will handle lots of other neat user interface object as well as aid in server-side management. I have included the script code used in this demo, not LUA but I think good enough for an interface system.

I have have a good base of code with my work on Phoenix USC all in BlitzMax but all of it written to port to Monkey X. So I have a great opportunity to design an awesome gaming framework and if MX2 has decent networking an online one at that. :)

Off to code,

Current interface script.



Richard Betson(Posted 2015) [#2]
Making great progress. Monkey X is doing great handling it all in GLFW and Android. Fired up for MX2. :D

If you are into IRC (International relay chat) I maintain a channel on irc.quakenet.org. The channel name is #phoenixusc and we hang out there most of the time. If you have any questions or just want to follow the day to day development of PUSC why not stop by and say hi. :) Monkey X and Blitzmax users are always welcome to talk shop. ;)

If you have a copy of the Phoenix USC preview demo just type F9 and you will be automatically connected to the IRC channel through PUSC's in game IRC client.


Richard Betson(Posted 2015) [#3]


Hi,

I have posted a new video showing off my current developments with Phoenix USC (porting) and my new 2D gaming framework Alien Phoenix (project code name). I am basically porting over what I did with Phoenix USC and establishing an independent gaming framework. The gaming framework includes what you would need to code a game including physics, mapping, user interface, graphic interface, networking and more. If it were not for all the work I have already done (Phoenix USC) this would be a 'tall order' indeed but fortunately all of what I did in BltzMax will port over to Monkey X with only minor efforts. So as I do port over code I am taking the time to organize it all into a very seamless and efficient gaming framework all of it in native Monkey X code (that's the plan :) ).

In viewing the above video you can get a good sense of how the framework preforms and just how useful the graphic user interface is. The window or maybe a better description would be container based GUI allows a great degree of flexibility. The gaming framework exploits the window system by having one branch/hop access to the rendering window images (images included in window image draw list). Where the Monkey X program adds an image to a window image draw list and it is drawn on the next window update which adds near zero lag to image draw to display times. Images are managed by the window system along with view port clipping (fully adjustable) and aspects like rotation, alpha, blend and position. All this makes it incredibly easy to draw images to windows and not have to worry about any management. You can also draw images to windows once and let the window system manage them, later clearing/removing them when needed.

I have also ported my weapons system which uses the physics framework. Each 'bullet' is it's own entity. So all the inertia aspects can be applied like velocity, spin, angle, friction, gravity and more. This makes for awesome effects in weapons physics wise and coupled with animated images for bullets renders a nice gaming experience. Using the methods I have now I can maintain about 5000 entities on a low-end duel core PC with on-board video and still have reasonable gaming performance. This is based on what I can do in Phoenix USC and that's on top of managing a map, rendering it and managing collision. So much of what I am bringing into this game framework is tested and designed for high entity counts.

I am also continuing work on the user interface system which is in place to use scripts (see above post) to manage all the user interfaces in a game. This has the advantage of being able to load in user interface script files that configure the interfaces for a particular platform. The goal here is to just use a default script file to setup the user interfaces so that you could have a PC script or a mobile script and the interfaces will automatically adapt.

Android/Mobile
I have this running on Android and am just getting it up to seed. So far the interface performs well. With increased landing zones for window resize spots the experience is very 'CSI' like (ya know the cool future touch interfaces). Being able to manage and move windows like that is a neat thing. On my 11.6" tablet my brain immediately surged with ideas and uses for it. Still the GUI/User Interface can easy be adapted to suit so many kinds of mobile interfaces including more tradition styles. Touch controls are a fairly easy thing to implement as they can be in topmost windows and have buttons or other controls, I will be adding those here shortly and posting a video of all of this on a Android tablet.

At present Monkey X does not support external keyboard input, which is sad (hoping for external hardware support in MX2). Using the keyboard and track pad provided on many tablets today really gives you that PC experience (especially when using a mouse) when used with the gaming frameworks GUI in the above configuration. So sweet for more complex tasks or games. So at present I will work on some sort of touch only interface for player controls.

I am just getting started with this project but I am making great progress and really getting to know Monkey again. ;)
- Rich -

'
Edit - It appears I was in error (not the first time :D ) and Monkey X does support external keyboards. It may just be an issue with certain keys I was using exclusively that may not work.


Amon(Posted 2015) [#4]
Awesome stuff! You're quite gifted as a programmer. Jealous................:)


Richard Betson(Posted 2015) [#5]
*Blush* Thanks man.. made my day.


Richard Betson(Posted 2015) [#6]


Hi,

Above is a video of the new gaming framework running on Android 5.0 . It is the same exact code as before (above post - Windows demo) except for additional touch support code which looks for two separate touches. The GUI component framework now supports multiple touches (2 for now). It was not to hard to add and allows the GUI components framework to work with more then one button at a time (most GUI components use the button class). So the result is the ability to have on screen controls where certainly more then one button is being pressed. By the way I put some on screen controls in a window and demo them about mid video.

Let me know what you think of this running on Android. It's just a straight up use of the GUI/UI for PC and on my 11.6" tablet and is sure fun to mess around with. With Phoenix USC I am aiming at tablets and displays equal to or larger then 9", but the gaming framework can be made to support almost any display. I really believe tablet gaming (larger the better) is the next big thing for gaming on Android and most of the data I have looked at bares this out quite obviously. Tablet gaming looks to be the most profitable and fastest growing segment of the Android gaming market and the Alien Phoenix 2D gaming framework will focus on supporting it. This means more complex and richer interfaces as an option and even a more PC like experience. For example this test on android functions just like the PC version when the tablet uses a Bluetooth mouse.

With this test I wanted to make sure the gaming framework was going to run OK on Android and it does. The performance is very similar to my duel core desktop with on board video (Emachines..ek). So I am fairly impressed by the performance I am getting and the gaming framework looks good on Android. I will be stepping back a bit and now working on the user interface scripting and support code and smoothing out some other issues.

So far so good though, :)


Richard Betson(Posted 2015) [#7]
Been in the top 5 last 24hrs on slidedb.com (Indie DB mobile) . Getting positive feedback on a window based GUI for tablets. Also doing my part for Monbkey X
http://www.slidedb.com/games/phoenix-universe-of-space-combat

Could the world be ready for a touch controlled window based GUI on Android tablets? :)


Richard Betson(Posted 2015) [#8]
Make that #1. . . First time in the number one slot. :D
http://www.slidedb.com/games/phoenix-universe-of-space-combat


Richard Betson(Posted 2015) [#9]

.


Hi,

I have been converting my code to work with mojo2. Above is my GUI running in a native 1280x720 and the same GUI app scaled down very small in Glfw. It actually works very well using a virtual resolution in mojo2 provided by mojo2's SetViewPort() and SetProjection2d(). This virtual resolution allows the GUI to work in any resolution and still function as intended. A very useful feature for tablets / mobile and PC's and will make it easy to layout the interface for one resolution and the framework will automatically scale to fit any given display.

The colors are off as I am still changing all the SetColor() commands to work with mojo2's 0-1 format. I should mention that mojo2 SetScissor() does not work seamlessly with SetViewPort() so you have to scale the variables manually to match the view port.

So I am converting the rest of my framework and then back to development. ;)


Richard Betson(Posted 2015) [#10]

Android - Phoenix USC / Alien Phoenix gaming framework

Hi,

I now have all of my framework using mojo2. The above video is a look at the recent changes to the gaming interface (GUI). Of special note is use of a projection matrix which keeps a static virtual resolution in this case 1280x720. So the GUI/Interface is automatically scaled to the device display dimensions. It even works when changing the device orientation from landscape to portrait (as seen in above.. mid video). The framework interface will adapt the projection matrix (and much more) to the device orientation dimensions.

I am also using the GUI button framework to add a 'dish' style navigation control which works great for the game application I am building. It affords really accurate control and a natural feel when testing. I've also added slider control to the console window which now uses a string array managed by the window framework. Changes have also been made to window borders, now more accurate on resize corners and boarders now disappear when maximized. Lots of other little fixes.

So after converting my "studio" operations here to Linux it feels great to finally get back to coding.


Paul - Taiphoz(Posted 2015) [#11]
That's looking really cool... nice work bud.


Richard Betson(Posted 2015) [#12]
Thanks man. ;)

Just starting to add mojo2 lighting and shadows. Will be cool to see that going.


Richard Betson(Posted 2015) [#13]

Mojo2 - Scrolling map with lighting and shadows!

Hi,

Above is a video of the Alien Phoenix framework running a 'scrolling' lighted map scene. :D Complete with one lighted game map scene window and two other interactive game windows that use no lighting. I have the touch screen overlay (buttons) also running with the lighted map scene for testing. This was recored on my Linux Mint system. This framework is doing well so far with with mojo2 and I am starting to get a handle on ways forward for large map scenes using many renderer instances. I still have some learning curve ahead on mojo2 and rendering, but I think I am getting a handle on it now. So far integrating of mojo2 Renderer and associated framework seems very doable and on the face of it looks to be easier then I had expected..although time will tell. :) Seeing a lighted scene in the frameworks GUI made my day.

Off to code...


Richard Betson(Posted 2015) [#14]
A recent post of the above video has me #2 on Slide DB today. Minecraft then me... LOL.. rankings are fleeting but fun to see. :)
http://www.slidedb.com/games/phoenix-universe-of-space-combat


Manuel(Posted 2015) [#15]
Congrats on your ranking! I was checking out your post and I have to say that you did a really good job on the graphics, I like how the space ships have motion when you turn. Also the music you are using I fell works great on your game. Congratulations my friends! keep it up.


Richard Betson(Posted 2016) [#16]
Hi,

I have had a bout with illness (last month or so, all well now) which cut into development, but back on track. :) I have been finalizing my GUI architecture which is a huge factor in designing my gaming framework as it handles quite a lot from managing windows and GUI components to supporting a window draw list that manages text, images and mojo2 rendering. I am happy to say that it is all working awesomely and is 'Very' efficient with each window supporting an Independent list of buttons and GUI components as well as a draw list (draw images, text and mojo2 render). This and other consideration in design make this GUI perfect for gaming. As it stands now the core architecture is well defined and functioning well so it is now time to flesh out the GUI components.

List Boxes and Menus
Below are a few screen shots of list boxes used in the GUI. I have reworked my code to support '4' images per button, one for up, down, highlight and selected. This makes for really detailed and flexible buttons especially when supported by framework commands like SetHighlightColor(), SetHighlightAlpha(), SetHighlightBlend() and alike. Each button (or list box element) can have a separate button image for all four states of action as well as '4' states of color, blend and alpha. In the first list box image below you can see the highlight element in the list box using BlendMode.Additive as well as a custom color and alpha. When it comes to list boxes you can customize list box button elements as a group or individually and this even extends to changing individual list box button element images. So the up shot here is list boxes are very customizable as well as buttons and sliders.

I will be using the list box class to support menus. As it stands now list boxes can have a slider on the left or right or no slider at all. So with some small modifications the list box class can support a menu class. The plan is to support at least a first level slider option for menus which may extent to sub-menus. Since the list boxes provide support for element images menus should really function and look sweet. I should add that the GUI loads a resource file to 'skin' and initialize. So all of the GUI components (buttons, list boxes, sliders, more) are ready to go with all of the default color, blend, alpha and images. This allows for a overall theme and lots of customization.


This list box (over rendered mojo2 scene) uses customized color, alpha, blend for its button elements. The slider is also customized using list box framework commands (alpha, color, blend). Shown in cursor highlight state.
.


This is a list box using the default skin and framework values. Shown in cursor highlight state.
.


Also using the default skin but shown with the cursor element state in the mouse/button down state. Each button (or list box element) has '4' images for each button (or list box element) state as well as the color, alpha and blend states.
.

So I still have a lot to do but I am in the home stretch as it were. With the core architecture firmly in place fleshing out the rest of the GUI components will happen quickly. After I have menus and a list box view in place I will move on to a text area component which will allow in game editing and so much more.

Off to code.
- Rich -


Richard Betson(Posted 2016) [#17]
Hi,

I changed the thread name as this is about the Alien Phoenix gaming framework now. Phoenix USC is the driving force but now that I can see the light I've changed the thread name.

FYI, as soon as I can I will post both a PC and Android demo of Alien Phoenix in action. :D

Off to code.
- Rich -


Neuro(Posted 2016) [#18]
Some really fancy stuff here :).


Richard Betson(Posted 2016) [#19]

Background screen casting awesomeness.

@Neuro - Thanks; it gets fancier. :D

Hi,

I just now have got background screen casting working (need to finish) which allows you to cast a window to the background screen. I have a little screen icon (you can see upper right background screen) which when clicked will cast that window to the background. You can think of it as sort of a bottom-most window (really a bit more complicated). Once cast all other windows will appear above it and work normally. Clicking on the cast window (background screen) activates it and all the GUI components will work normally (with all other windows above the cast window). Super cool and so right for gaming. I'll have a video up here in a day or two (soon) which should give you a good idea of how this works.

I'm also exploring virtual screens and I think I can make that happen code wise. Anyway, I was so exited casting worked I had to post about it.

Off to code,
- Rich -


Richard Betson(Posted 2016) [#20]


Hi,

I have background screen support as a feature supported by scripting. So looking at the image above you can see the background screen is composed of a background image, animated image (under my logo) and a static image (my logo). All of this is loaded and managed during runtime through a script (which will do 'much more' then just configure the background) file that looks like this (subject to change).



I also have the background screen casting feature working well and it really solves many issues regarding managing windows. Casting windows to the background is just a sweet feature. It allows any window to be cast full-screen to the background screen and automatically stops drawing the occluded scripted background screen images for efficiency. The same occlusion efficiency is done for maximized windows where any open window is not updated or drawn while occluded. I will have a video of this up shortly here. :)

I thought I would mention that at some point I want to make this framework available to my fellow Monkey coders (cost? not sure yet). So if you are a fan of what I'm up to you will be able to use this framework for your applications and games. I am planning to release the GUI framework first as it is the core architecture for the gaming framework and it manages all of the graphic user interface, background screen, windows and more and works seamlessly with mojo2 and Monkey (got to love native coded frameworks). Also I believe that this framework is flexible enough to work with existing gaming frameworks (although I have never tried any of them :O ). I will be fleshing out more about how to code for Alien Phoenix and sharing more about it's flexibility along the way. There is so much that this framework does I will have to lay it all out in several posts.

Personally I am very happy with the results and once finished, I believe you will not find a better, more efficient, flexible and capable GUI framework (gaming) for Monkey-X anywhere (not even third party). :D


Richard Betson(Posted 2016) [#21]

Intro to background screen casting

Hi,

In this video I explain a bit about the Alien Phoenix gaming framework and the new background screen casting feature. This video is aimed at Monkey coders and hopefully will help show why you might want to use this gaming framework.

Off to code,
- Rich -

>Made and recorded on Linux Mint :)


Richard Betson(Posted 2016) [#22]

.

Mojo2 Lighting

Above you can see the ship is lighted (and shadowed) as well as the rest of the scene. I'm getting a handle on the best way to approach map architecture and lighting and shadows. The more I dive into mojo2 the more I seem to like it. :) It should work well with my mapping framework from Phoenix USC.


Richard Betson(Posted 2016) [#23]

Two separate mojo2 renderer scenes.

Hi,

This is a screen capture of Alien Phoenix supporting two independent renderer scenes. Each in its own window and two separate instances of renderer and layer, including separate lighting and shadows. Looks pretty sweet and I'll post a video soon. The framework handles it all amazingly well with just a 12% CPU load (or less) with all windows open (including two separate renders) on my AMD Phenom II quad core. Very nice to see.

Off to code,
- Rich -


Playniax(Posted 2016) [#24]
Looking good!


Richard Betson(Posted 2016) [#25]
Thanks. :)


Richard Betson(Posted 2016) [#26]

Collision impact lighting.

Hi,

I have been prototyping mapping, collision and impact lighting and the above is a screen shot of collision impact and lighting, I am using 'ratking's' port of the hardon collider (ya thats the right name, got to love the love2d crowd). Although I am not pushing it very hard it is performing. The only real issue is the lack of a method to return the collision normal which I would think is solvable. You will also, it appears. have to layer collision. Aside from that it has preformed well and I am still exploring how and what it does. Right now I am able to support two separate scenes with independent collision, impact and other lighting. The AP (Alien Phoenix) framework does support any number of renderer and layer instances.

The lighting for the collision impacts is using two lights which pulls off a nice lighted impact effect (looks sweet) in real-time. It is quite convincing and the shadow casters really add to the effect of lighted impacts. I have impact animated sprites also showing as part of the the impact effect. So the impact effect is a combination of an animated sprite and a light underneath. Looks just great in real-time and I will have a video up shortly.

I will be doing more prototyping to reveal the best path forward for lighting, mapping and collision, but I think things are off to a good start.

Off to code,
- Rich -


Richard Betson(Posted 2016) [#27]


Hi,

Here is the video I mentioned about in the previous post. I demonstrate the real-time collision lighting effect running on two separate renderer scenes in two windows. Mojo2 is one sexy beast. :)

Off to code.
- Rich -


dopeyrulz(Posted 2016) [#28]
Nice - looking good Richard!


Richard Betson(Posted 2016) [#29]


Hi,

I have been experimenting with bump mapping.The above image shows the floor and red ship using mojo2's BumpShader. It's tough to get the normal and specular maps right on the tiny 64x64px ships but it seems to be working good. I am using Gimp to create the normals (via the normalmap plugin - add-on Gimp site) and specular maps which seems to do a fairly good job at it.

A word about HTML5
The only reason my framework does not support HTML5 is because of the file system. I am looking into methods to support file transfers from the web instead of locally and fortunately the framework does not require too much in the way of initializing resources. So I am looking into this and hopefully I can come up with a way to support nonlocal resources. Definitely on the to-do list.

Off to code,
- Rich -


ImmutableOctet(SKNG)(Posted 2016) [#30]
@Richard Betson: Looks great as always.

If you're interested in a file-system for HTML5, I wrote one previously. There's no support for 'FileStream' at the moment, but it's possible to implement. 'SaveString' works out of the box, though. Without making a custom target, it doesn't work for loading from the data folder, though. These are definitely things to look into.


Richard Betson(Posted 2016) [#31]
@ImmutableOctet(SKNG): Thanks, I will give your code a look-see. :)


ImmutableOctet(SKNG)(Posted 2016) [#32]
@Richard Betson: Just as a heads up, I've just finished implementing a highly experimental version of 'FileStream', if you're interested. It requires a proper installation of 'regal', though. Behavior is largely untested, but it's passing my initial tests.

Obviously, this isn't a final product, but if this is interesting to you, feel free to try it out.


Richard Betson(Posted 2016) [#33]


Hi,

Really happy with the GUE performance. The above image shows '5' windows running (all real-time, 'no' in active pause), two windows with mojo2 render scenes (1280x720), one window with a tiled background and images (non lighting/render) and two support windows. All running real-time together with a small '9%' CPU usage as indicated by Linux Mint's system monitor. :D

I have put forth quite a bit of effort to make this GUE and framework as efficient as possible and it's nice to see that effort paying off. :)
.

@ImmutableOctet(SKNG)
Wow.. I will check that all out and give it a try as soon as I can. I did have a quick look and it seems doable using the above. I would love to see this framework running in a browser and I think that the framework is efficient enough that it's performance might be surprising. Right now I am in the middle of laying out a design for map support using a quad-tree style architecture as well as fitting collision into the mix so my head is so there right now. In a week or two I should have the time to give the above a welcome try. :)

Off to code,
- Rich -


Richard Betson(Posted 2016) [#34]
Millions of map objects

Hi,

I have been working on a mapping framework and using a quadtree style architecture I am able to generate millions of map objects and support them in a fairly huge map space. Pushing things I can get about 5 million map objects in a map space before some issues seem to crop up. The map space is 83+ million pixels wide and can be larger. The map objects are simple and just include an image and it's coordinates but it is the coolest thing to generate millions of objects and have the map system manage and display them.

I'll have some more details soon. As it is now the entire map is held in ram (memory) and I am still working through the architecture but things look promising for large map spaces and very high map object counts. The 'leaf' portion of the treemap has been tested with several hundred map objects and in this case a leaf is part of a cell that is 1280x720px. This is good to see and map detail should be nice and high.

As soon as I have something to show I'll post a video. ;)

Off to code,
- Rich -


Richard Betson(Posted 2016) [#35]
Hi,

I am working out how to get all of the map objects into memory using the above and yet still be in range of mobile (tablet) limitations. I have implemented an architecture that is based on the quadtree idea but goes further then the a 2x2 block matrix and uses no subdivision on the rendering or drawing end of things which makes it efficient. The map is initialized by using a root of say 128x128 with each root node extended out to a child cell block of say 128x128 with each cell representing the display size (1280x720 in this case) . Each child cell then has a leaf list which is made up of all the map objects that are to be displayed. The system works well and the performance is great and with a root node block size of 128x128 and a child cell block size of 128x128 I can easily hold 2 million map object within memory and have a map size in pixels of 20,971,520px wide (root_width*cell_width*1280) and 11,796,480px in height . This for my Phoenix USC project is a huge space for an arena style game and will work for many other game concepts. On the rendering or drawing end of things there is no subdivision needed as all of it is baked into the tree structure so all I have to do is is extrapolate the child cell and leaf list that is in view (based on actor position). Typically there are always four child cells in view with each child cell having it's own leaf list of map objects.

The biggest reason to have everything in memory as opposed to smaller chunks is to avoid non ram access which on a server for example would not be a good thing. Also when using an authoritative server it is advantages to have the entire map in memory as the server needs to manage the entire map all at once. Typically I would think that a map is not going to have every child cell / leaf filled with map objects so 2 million is a fair stress test and on my cheap tablet runs well (no lighting). Another advantage using this style of tree mapping is I can include collision data within the leaf object list which gives me performance. Since the system is already working with a map object (in this case the leaf list of map objects would include vertices's) it is a simple matter to pass vertices's to a collision class and perhaps even shadow vertices's as well.

So the next step is to start to layer things up and see how that works out. My outlook is optimistic and I believe I can run several layers of tree maps even on mobile devices. As soon as I have that working I will post a video and explain a bit more on what I am up to.

Off to code,
- Rich -


Richard Betson(Posted 2016) [#36]

2 Million Monkey's in a parallax map scene

Hi,

I will post a video latter today showing 2 million monkeys (monkey logo) in a parallax demo of the new map system. The demo uses three map layers (plus one tiled background layer) to achieve a very cool parallaxing map scene. I still have some efficiency changes to make but the map system is working great. It is noteworthy that each monkey is a separate map object which is pretty cool. :)

Off to code,
- Rich -

Edit I had some video driver issues which I think I have fixed now. I'll get a video up soon as I can.


Richard Betson(Posted 2016) [#37]


Hi,

This is a video where I demonstrate the latest developments in my mapping framework featuring 2 million map objects. I also demo some of the bump mapping I am working on. I am getting some screen tearing with my video card and a recent driver update (ugh) so be aware that this all runs perfectly when not using screen capture software. I will be getting a new video card here in a few weeks which should improve things.

Off to code,
- Rich -


tiresius(Posted 2016) [#38]
That is really impressive I see some jitter every second or so I don't know if that is in game or just from video capture.
So with 2 million objects how do you prune what the game cares about do you have objects broken into zones or AABB rectangle type stuff?

Very cool !


Richard Betson(Posted 2016) [#39]
@tiresius

Ya, the screen capture software is causing that and it may not be it's fault. The demo runs perfectly when not capturing video and this probably has to do with the AMD Radoen card I have and Linux as most everything I've come across praises Nividia and pan's AMD. So I will be getting a new Nvidia video card and hope it fixes the issue.

To 'prune' (it's more like draw whats in a cell) non-viewable objects I use the players position and calculate which cell's are in view. Each cell has it's own list (really an array ATM) of map objects so it just a simple matter of drawing objects that are in view within the viewable cell. If you look at post #35 I kind of explain how I am doing this (not AABB). I am working on a little tutorial that hopefully will layout the specifics along with a code example. It's actually pretty simple code wise (at it's core just stuffing map objects into a node/tree structure) and there are a few limitations in regards to memory usage (above 2 million can use up memory) but at 2 million it's only a few hundred kilobytes (maybe a bit more). It is however very friendly in performance and cost very little in the way of CPU usage.

So check back later (I'll need a week or so with my current schedule... super busy) and I'll have a tutorial. ;)


Pakz(Posted 2016) [#40]
Watching the video makes me want to program a small game like that in Monkey today. Something like :

http://www.blitzbasic.com/codearcs/codearcs.php?code=3155

I have no idea what I would do with a map system like you talked about though. This with the only update what is on the screen aproach :)


Richard Betson(Posted 2016) [#41]


Hi,

I am close to finishing the mapping system. Here is an image of 'five' separate parallaxing map layers plus a player and tiled image layer (star field background). In total there are just over '1 million' separate map objects in this demo map and that is just the background portion of the map.

I'll have a video of this soon, just as soon as I work out the last few little design/coding issues. I have looked around the net and I can not find a similar method to the way I am doing things so maybe this is a new approach. I still have a few issues to work out but as soon as I get them solved I can post a little tutorial on how I am able to manage this.


Richard Betson(Posted 2016) [#42]


Hi,

Above is a video of the new mapping system I am developing using 1 million map elements with 6 layers of map spaces. Each map space is about 41x41 million pixels in area. All working within Alien Phoenix's GUE. This video also includes lighted map elements.

Still lots to do but the mapping framework is shaping up nicely. ;)

- Rich -


Richard Betson(Posted 2016) [#43]


This is a test of the new map system only with a static background instead of a tiled image one. I think it looks better.


Richard Betson(Posted 2016) [#44]


Hi,

I have the new mapping system working on my Android tablet with 1 million elements .. yay! I had to drop the huge space station images as they were blowing out the tablets memory capacity, but I think with some tweaking I can get at least some version of them in. Even with them not in the map I still have three map space layers (asteroids) going over a static background and it is pretty cool to play around with and has a very nice look and feel. I'll be posting a video of this running on my tablet very soon. ;)


lom(Posted 2016) [#45]
Very interesting mapping system :) Would be cool to see some code though


Richard Betson(Posted 2016) [#46]


Milestone: Same GUE and map on PC and Android (image) using 1 million elements. Space stations and all. So cool.

Through some improvements in memory management the mapping system is using memory more efficiently (quite a bit). This of course allows me to add in more map elements to mobile. It is pretty cool to see the exact same GUE and map running on both the PC and Android and this is one of my goals, allowing a seamless gaming experience.

1 million map elements is quite a lot but during development it is a good thing to stress test the map system.


Richard Betson(Posted 2016) [#47]
Hi,

I am just about to get collision going in this new map system. The map system now uses a parts system that manages all parts for the map system. What is a part? It is an object that holds all of the data needed to be added to the map systems as a map element. So a part object would include the image, alpha, blend, color, collision data and more. The part system loads two text files which hold this data and below are example of the data in these text files. With these two files a part can be described and defined as a part object and then can be used throughout the map as map elements. I'll explain more on this later but the basic idea here is you define part objects and then place or add them to the map space (you can have lots of map spaces or layers).

I also wanted to mention about the frameworks efficiency and performance. In the above video (post #43) you can see the mapping system running in a full-screen (maximized) window. In that mode the CPU usage on my 3.8ghz quad core is 3% (yes that little) and in the multiple window mode (3 windows in view) the CPU usage is 11%. These kinds of CPU usage numbers are what you need to have a shot at mobile devices. I believe I can reduce the higher 11% number down a little bit further which means CPU usage is not a factor when using this framework and mobile devices.

As soon as I have the collision aspect of the part and map systems going (very close to having it working) I will post a video of the Alien Phoenix framework running on an Android tablet using the 'exact' same map and 'window based' GUE as is on the PC. Looking around the net I have not seen anything like my approach and if things continue to workout as well as they have this framework will provide the first truly seamless window based GUE/GUI for PC and mobile. This should be noteworthy and I may put together a simple shoot'em up style space game to test the reaction to this unique and useful gaming framework. I think it's cool of course, but I hope others do too. :)

Part data file.


Part collision data file.



rIKmAN(Posted 2016) [#48]
Looking good!

What are your plans for the framework in terms of release?
Is it going to be internal only, free, paid etc?

Keep up the good work.


Richard Betson(Posted 2016) [#49]
What are your plans for the framework in terms of release?
Is it going to be internal only, free, paid etc?

That is a good question. :) I definitely want to release this to community and with Mark mentioning that third party GUI's or this case GUE should be considered for Monkey 2 I think there is a need for such a framework. The issue for me is should I charge or not and to be honest I am still not sure how I want to approach this issue. Typically, my experience is successful frameworks related to BRL products have charged for the use of a framework or module. I can see why as maintaining, promoting and supporting a framework over time is costly in time and money; for example I have almost a year of development in this project to date. Playniax's Pyro (and his other products) is a good example of author support and development and may be a model I will pick up on. His products are up to date and supported largely impart to his passion I bet but also the monetary component that helps support costs (website, hardware, time invested and so on) . I think this is a path I may emulate.

My goal is to provide a useful gaming framework that is supported, maintained and constantly improved. To do this I believe that some sort of licensing would be an option to consider. For example allowing the framework to be used under license for free in a non-commercial setting and for a fee in a commercial setting. This appeals to me and might be what I ultimately choose to do. The bottom line for me is to make the framework self sustaining in that the costs and time invested have some return.

I am open to suggestions if anyone has an idea on this topic.


Richard Betson(Posted 2016) [#50]


Hi,
I have collision working with the map system and it seems to work really well. Above is an image of it working on Android (tablet). So far the performance is great and in a day or two I'll have a video of framework running on my tablet. I'll explain more on how the map system works with collision then. :)

Really happy with the performance so far.


Playniax(Posted 2016) [#51]
I can see why as maintaining, promoting and supporting a framework over time is costly in time and money; for example I have almost a year of development in this project to date. Playniax's Pyro (and his other products) is a good example of author support and development and may be a model I will pick up on. His products are up to date and supported largely impart to his passion I bet but also the monetary component that helps support costs (website, hardware, time invested and so on) . I think this is a path I may emulate.

Yep, it is a full time job and I love it! Yes, we charge a little money but basically every euro goes back into the framework and support right now. If your passionate about it then go for it!


Richard Betson(Posted 2016) [#52]
If your passionate about it then go for it!

Passion for sure.. or maybe it's crazy, for spending so much time on this project. :)


Richard Betson(Posted 2016) [#53]


Hi,

This is a test of Alien Phoenix's mapping, collision and GUE systems on my 'low-end' (Walmart buy) Android tablet. It works nicely on Android and in full screen mode runs at 60FPS. The mapping system now supports collision and although for now it is pretty simple I will be adding vector rotation to it and other needed features. I had to roll-my-own to get the performance I was looking for. So far I am happy with the frameworks performance on mobile and given the features provided by the GUE there is really nothing like it. :)

Be sure to checkout the last part of the video to see window on window views.


lom(Posted 2016) [#54]
@Richard Betson
Do you keep your level objects coordinates in an external file? Or everything is procedurally generated?


Richard Betson(Posted 2016) [#55]
Do you keep your level objects coordinates in an external file?

I do keep all of the map elements in a map file. The entire map is held in memory as well. For a little bit of background see post #47 which describes how I am laying out the map system in regards to map elements.


Richard Betson(Posted 2016) [#56]

Working out the parallax view in this video. I think it looks better and the planet moves as well which helps the effect. Still having screen capture issues (new video card soon) but I think it gets the idea across.

I'll be moving this framework to Monkey2 soon so the lighting portion of the mapping system will have to wait till I get this running on Monkey2. Which brings up the issue of supporting Monkey-X. I can't see trying to support both languages as an option and Monkey2 will be what this framework ends up supporting. The differences in the two make it difficult to maintain two code bases. I might have a change of heart once I get through the conversion but at first blush I feel sticking with Monky2 is the best path forward.


Richard Betson(Posted 2016) [#57]

Same map and images but with a lighting effect and color on the asteroids. Also a slight change to the movement of the parallax layers.

Getting there...


Richard Betson(Posted 2016) [#58]

Parallax map view version 3
.


Third times a charm. :)

Instead of trying to be accurate in distance and depth for the parallax map view I chose to go for a stylized look and feel. I darkened the bottom layer of asteroids, added two galaxies images using an additive blend (over a static background), added another planet image and quickened the the planet movement rate.

I think this works. :)


Richard Betson(Posted 2016) [#59]
I am working on version 4 of the map. I've dropped the static background (under galaxies) to make galaxies pop and made some other tweaks. The map system rocks! Very happy with the system I have developed and it's nice to have a little fun building a map to test it.


.



Richard Betson(Posted 2016) [#60]

.
About Mapping
I wanted to mention that this framework now uses two classes of mapping. The first is a map tree which is used for the bulk of the map and supports collision and hundreds of thousands of map elements. The second class is map image. Map images are generally used for background/foreground elements in a map and like map tree can be layered. Both systems create a map space that you put elements (parts for map tree and images for map image) into and each map space (or layer) can be drawn independently. This give a nice degree of flexibility when constructing a map.

The map tree collision can be used independently as well and for example if you want several layers (or map spaces) of collision you need only add map parts defined with collision vertices to a map space. You can then draw the map space, or not, ( DrawMap() ) and then additionally check the map space for collision ( MapCollision() ). Using the physics (simple inertia for now) and collision (also fairly simple but simple is good and fast) frameworks you can pass along a physics objects position using MapCollision() which returns true if a collision has occurred. You can then poll GetCollisionNormal() to retrieve the normal and also GetCollisionCoord() to get the collision coordinates. I'll probably be adding a GetMapElement() to return the map element or part involved in the collision plus other methods to assist in interactions.

So thats sort of a simple overview of how the map and collision systems work as of now. I'm still fleshing out how I want to approach this but, so far, it is working out well.


Richard Betson(Posted 2016) [#61]


The framework is running nicely on mobile. Here running on Android. I've put more separation between the asteroid field and the ship / collision layer which helps visually.


Richard Betson(Posted 2016) [#62]


Hi,

For those who might want to use this framework when it becomes available I thought I would ask your preference on syntax and command structure. Below is the code it took to make the list box above (ON Monkey 2). All of it save, CreateListBox() (could use New() instead) and AddElement() are 'not' needed as the default settings could be used (predefined color, images, blends and more). But, if you wanted to customize a list box there are more then a few commands to do it with. I am converting this all to Monkey 2 and I am reworking some of the code to better fit it. I plan to leave this as it is (the commands / methods) as I do not see a benefit to making this all property based. I thought for those using Monkey 2 (or planning to) I'd see what you might think on the subject.




Richard Betson(Posted 2016) [#63]


I just got a new AOC 27" 1080p LED back lighted monitor with a '2' millisecond response time and IPS display! I can't begin to describe the difference from my old 19". Love it! Aside from a giant screen I can now see way better color definition which is what I need for game art/assets development. Such a treat to work with code on this.

I also just bought a Zotac GTX 950 AMP! video card . It should be here Friday. :D With the new monitor I can now push forward in development as my current video card and monitor were not letting me get the job done. The Zotac GTX 950 AMP! benchmarks at about 90% of the performance of a GTX 960, is less expensive and has better compatibility with Linux (I use Linux as a development platform) then the GTX 960. It also uses less power with a 90 watt rating (uses a 6 pin connector). So overall a very good bang for the buck.

I finally saved enough to get what I needed. It's awesome to step out of a 720p world and into a 1080p one and this new graphic card should let me capture video without any issues.

Zotac GTX 950 AMP! on amazon.


wiebow(Posted 2016) [#64]
Love your backdrop! :)


Richard Betson(Posted 2016) [#65]



Hi,

I've posted a new video at 1080p. :) This video shows off the newest version of the parallax (v-5) with a display resolution of 1920x1080. The map now supports rotation for all of the background asteroids, so they all rotate (except collision layer ones) in this map. Additionally I have made some tweaks to the parallax layers for better viewing. I've also added a new planet (larger size) and a new star field background. The new hardware has proven to be nice and useful.

I've been working on converting the Alien Phoenix framework to Monkey 2 (video shows app made with Monkey-X) which is going well and affording the opportunity to improve things. I've been a little sidetracked by new hardware but that's a nice diversion to have. Anyway, back on track.


Richard Betson(Posted 2016) [#66]
Hi,
I have moved this discussion to the Monkey 2 forum. :D The saga continues here.