Alien Phoenix - Android - IOS- PC
Community Forums/Monkey Talk/Alien Phoenix - Android - IOS- PC
| ||
| Hi, Above is a video of my gaming framework in development for Monkey-X. This is a test of the frameworks interface/GUI on a mobile device. It also uses Mojo2. Alien Phoenix is a gaming framework I am developing for my own game project Phoenix USC. Really looking forward to Monkey-X2. :) |
| ||
| Looks great :) |
| ||
| Thanks, Most of it was developed first on BlitzMax. :) A window based GUI on Android that works seamlessly (so far) across PC as well. I get a lot of positive feedback on the Android end. The best of both worlds. :D |
| ||
| Hi, This is a test of mojo2's lighting and shadows while scrolling the render scene (side scrolling in this case) using SetCameraMatrix(). I'll be including this feature in the Alien Phoenix framework. Really staring to discover mojo2's potential and I like what I see. :) |
| ||
| That looks nice....a little too sharp the shadows - a bit of softness around the edges would make them much improved but it seemed good. |
| ||
| a little too sharp the shadows I have the bumpmap images using a matt shader so it's muted for some contrast. Be assured once I add this into the framework it will really pop. :) This is just my first test with mojo2's renderer and getting the scene to scroll. I am actually moving a camera view left and right. Renderer is managing the tiled images, shadowcasters and lights (aside from positioning) on it's own here, more like a 3D engine. The more I dive into mojo2 the more I like it. Edit - The code for that little demo is here. :) http://www.monkey-x.com/Community/posts.php?topic=10187 |
| ||
| 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 recorded on my Linux Mint system. Mojo2! +1 |
| ||
| Looks nice :-) Just for fun, this is what the equivalent BlitzMax source of your demo looks like : API is slightly different because this is based on Monkey2's mojo2, but the core stuff is essentially the same. Rendered output is exactly the same as your video in post #4. (as you'd expect) ;-) |
| ||
| ^Oh, neat! I just love to see code crossing over and with little effort it appears. +1 |
| ||
| Where can I find the png used in that sample (t3.png) ? I tried to make my own but always get "invalid texture format: 4". |
| ||
| 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 @Pingus It's included in Monkeys modules/mojo2/bananas/rendererdemo/rendererdemo.data/ folder. You can also make your own (128x128 for demo code) here: http://cpetry.github.io/NormalMap-Online/ Just make sure you save the normals and specular maps as follows: yourimage.png yourimage_NORMALS.png yourimage_SPECULAR.png Mojo2 looks for those tags (_NORMALS and _SPECULAR) at the end of file names to know what map to load. |
| ||
| Ah ok make sense if it looks for other files. Thanks Richard. |
| ||
| Share from my monkey thread. Making good progress on my framework. ;) 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 - |
| ||
 Background screen casting awesomeness. 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 - |
| ||
 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 |
| ||
| 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, that is some serious GUI eye candy you have going on there, exceptionally impressive work - good luck with your framework. |
| ||
 .  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. @Blitzplotter Thank you. I have a vision! :) |
| ||
 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 - |
| ||
| The framework handles it all amazingly well with just a 12% CPU load Hah ha! You'll be lucky to get one of those running smoothly on mobile. The lighting stuff in mojo2 is super resource hungry. :o) |
| ||
| Hah ha! You'll be lucky to get one of those running smoothly on mobile. The lighting stuff in mojo2 is super resource hungry. :o) In Monkey-X1 you would be right, but this on Monkey-X2 has a shot as it (to my understanding) will address some of those issues. The way MX2 is going to handle certain aspects of memory/data will improve things quite a bit. I will 'go out on a limb' here I guess and project MX2's performance regarding mojo2 will be twice as fast/efficient then it is now with the removal of certain bottlenecks to architecture. I should point out that this framework is being developed in MX1 while I wait on MX2 and it will all be converted to MX2. Fortunately all of the above lighting can be faked a bit by rendering it, capturing the scene in tiles (or whatever) and displaying those in a map as a static lighting scene (no lighting just a pre-rendered lighted scene). Something I will support as this framework is up to the challenge. In fact you can see this framework running with no problems (no real-time lighting) on mobile in the first video listed in this thread. My point on the 12% CPU load (it's actually lower then that) is that the framework is 'very' efficient and in 'no way' is a factor in bottlenecking development. In fact this is the fastest, most efficient GUE (more then a GUI now) I have ever used with any BRL product by far not to mention capable of features not seen here and all in native code. I believe that this framework on MX2 will be surprising in it's mobile lighting/rendering performance. ;) - Rich - |
| ||
 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 - |
| ||
| 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 - |
| ||
 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 - |
| ||
 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. :) Off to code, - Rich - |
| ||
 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. :) For more information on the map system checkout the Alien Phoenix thread on the monkey forum. Off to code, - Rich - |
| ||
| 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 - |
| ||
 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 workout but as soon as I get them solved I can post a little tutorial on how I am able to manage this. |
| ||
| 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 - |
| ||
| Just to give a short feedback judging on the video: - drawing 1 million map elements simultaneously is the interesting part, not managing them (except handling them _all_ regardless of distance to player) - how does the player know which asteroids are on the same layer/depth than the ship? Are asteroids never on the same level than the ship? If so I think they really distracted me when watching - always thought "now this one will crash the ship". Nonetheless I liked their look (maybe add more variety on "colors" - like different materials on these rocks, some might glow a bit depending on gases). - personal thought: the "rock music" and your dark toned voice made the video a bit "I am the cool one, what about you?". I understand that you cannot change your voice but if you did it intentionally (speaking a bit darker/slower) you might give your normal voice a chance. If this was your default voice, you cannot change that :-). I just am telling you this, as I know that everybody hears his own voice differently to others (I think mine isnt too dark, but others tell something different). bye Ron |
| ||
| Very interesting, looks great! :) |
| ||
| Looks great! 1 question: why do the bullets move with the ship after firing them? They seem to be linked to the ship, which doesn't look right to me. But maybe that is your intent! :) |
| ||
| Maybe the ship is having a gravity-based engine to move, so it manipulates the gravity surrounding the ship - and this means it also manipulates fired bullets. BTW: there is no reason to see "laser shots" at all: you see them, when they hit you. But this is Sci-Fi, so I won't blame that factual error. bye Ron |
| ||
| Perhaps they are "photon torpedoes" or such like, thus being a "something" rather than some form of boosted light source :-p |
| ||
| Like said: I fully accept that there are laser beams and so on. A game in space without sounds (except engines in your own ship - or the explosion of your own ship) would become really boring for your ears. bye Ron |
| ||
| @Derron how does the player know which asteroids are on the same layer/depth than the ship? The map is laid out in layers with each layer an independent map space. In the video I have 5 layers of map spaces all moving at different speeds (velocities) with the larger asteroids (top most layer) moving (inversely) 80% of the player speed and the mid-size asteroids at 65% of player speed and so on. The lighted layer is an additional map space. Together I can achieve a parallax view using this method. Map spaces are at the basic level a tree map with an array of nodes that branch to other arrays of nodes. So one root level node branches into an array of child nodes with each representing the display dimensions. From my point of view it is sort of a lookup tree (think lookup table - old school) where I lookup what elements (leaf items/collection) are in the child node based on the players position. So managing layers of map spaces is easy to do as basically all you have to do is create a map space, add items (elements) to it and then draw the map space (which manages what to draw based on position). In pseudo code it would look something like this to set up and use a map space.
'Initialize
map_base:PMap=New PMap 'Pmap is the main mapping class
map_base.CreateMapTree(32,32,32,32,1280,720)
'CreateMapTree - (root array width, root array height, cell array width, cell array height, cell display width, cell display height)
'Add items in this case images
For Local mapc:Int=0 To 500000
map_base.AddMapItem( my_image, Rnd(200000), Rnd(200000) ) '(image, position x, position y)
Next
'Draw the map space
map_base.DrawMap(player_x, player_y, window)
'DrawMap - (player position x, player position y, Alien Phoenix window to draw to)
Soon I will be using map part objects instead of images when adding elements to the map space. Each map part object contains all the information needed to provide an image, collision data (if needed) and other information to the mapping system that will be used to essentially copy data from the part object to the map systems tree map. If the map space uses collision then a return from a method or function will indicate a collision has occurred. So drawing a map space with collision enabled as say the top most layer (generally the player level) will allow for collision interactions. I am still fleshing out the best ways to approach collision and ways of making the map space dynamic, for example including player objects. As it is now the player/actor object is 'not' part of the map space and I am testing out methods to include player/actors and see what results I get. It should be possible to include hundreds of player/actor objects and potentially thousands of bullet style objects within the map space and support collision for them. Still, it may turn out that it is more efficient to use the map system to compare a player/actors positions to a map cell and the collection within. So the basic takeaway here is that you can have lots of map spaces, you can layer them and the map spaces that have collision enabled will provide player/actor collision. drawing 1 million map elements simultaneously is the interesting part, not managing them (except handling them _all_ regardless of distance to player) This is done by looking up the child node cell (based on position) and then getting a list (array) of elements (images and positions in this case) in that cell. I include neighbouring cells (each cell represents the display dimensions) for a total of 9 from which I extrapolate which map elements to display. As soon as I can I'll explain this in a tutorial. "I am the cool one, what about you?" Definitely on my quote of the day list. :D That actually is my natural voice although I recorded the video about 3:30am after getting a bit frustrated with my screen capture results so maybe that is coming through with my voice. At any rate I will be improving my delivery overtime as I get used to speaking (not my strong point - I am really a soft spoken person) publicly on videos. @Wiebo why do the bullets move with the ship after firing them? Every bullet style entity is an independent physics object. This means each laser, bullet, bomb and alike has it's own inertia physics and can be effected by the ship's (ship firing it) speed (velocity) and angle. Essentially if the ship is standing still it will shoot bullet entities as you might see in a stock shump but in a SubSpace style game each bullet entity has it's own inertia physics which adds to the skill and fun. Each physics object loads it's own configuration file with variables on how to act when initialized and can be changed to act in an inertia style or a non-inertia manner. |
| ||
| @ how you manage layers and collisions I know about that approach, thanks for repeating it but this wasn't what I tried to ask. I tried to ask how the player recognizes asteroids as being on a different layer ("not dangerous") - when moving the 80% decreased "asteroid velocity" is not obvious. Hard to describe for me but: when moving, is there an easy way to recognize an asteroid to be on "crash course" to you - or not ? @ 1 million map elements Again: your "1 million" approach sounds as if you handle and draw 1 millions objects simultaneously. You do not do this, you do not render 1 millions objects at the same time on the same screen. You skip render when offscreen etc. . This is what I wanted to express with "the interesting part". The checks whether offscreen or not are done similar to an octree approach. (is the area the element is in is already not on screen, then all elements in this area are not on screen). @screen capture results Some jittering is always happening as soon as you target android/html5 as Monkey draws at integer positions (not floats). Means: faster objects might move "back" by a portion of the pixel while the players eyes assumed it to be drawn on nearly the next pixel. @voice tone In this case you need to take care of the words you use (harsh words with a dark tone sound more aggressive, or "pseudo-cool" imho). Did not pay attention of whether you say such things, so just a general hint (as I had these issues in real world too). PS: do not understand above's things as "attack", just asking things coming into my mind when seeing videos/reading texts. bye Ron |
| ||
| @Derron This is what I wanted to express with "the interesting part". The checks whether offscreen or not are done similar to an octree approach. Not an octree approach in what I am upto. I will explain my approach here soon in a tutorial as that is probably the 'only' way to describe what I am doing. ;) This includes your interest in collision and map space layers. But, I am indeed only drawing what is in view (on screen) and within a child nodes leaf or collection list. Also, it is the interesting part for sure and my mindset when developing this map system was to have all elements in memory and search/sort through them as quickly as possible. The quickest way is to to presort all of the elements into a tree structure that represents the entire map space. In this manner it is a quick and fairly easy task to find what is potentially in-view (on screen) as well as what objects are nearby that may receive collision. do not understand above's things as "attack", just asking things coming into my mind when seeing videos/reading texts No problem. :) |
| ||
| Still unanswered: How does the player (not the developer) recognize asteroids as being on the same "height"/"depth"/z-index than the own ship. bye Ron |
| ||
| 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. |
| ||
 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. ;) |
| ||
 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. |
| ||
| I like the video. I think the ship looks a little out of place compared with the background...mismatched styles. I'm curious as to how the game will play. It reminds me a little of star control and i wonder if it will have a story based campaign. |
| ||
| I think the ship looks a little out of place compared with the background I am just using whatever assets I have around to test things so it is not exactly what the game would look like. This thread it is about Alien Phoenix which is my gaming framework. The game this is all for is Phoenix USC ( www.phoenixusc.com ) which is inspired by SubSpace also know as Continuum. It will be basically an arena combat game with an RTS component. I'm curious as to how the game will play. It reminds me a little of star control and i wonder if it will have a story based campaign. If you Google SubSpace and Continuum you should be able to view a few videos on game play. You can also go to my site where I have videos and even a working demo (done in BlitzMax) available. The basic game play is arena combat and then extends to league matches and so on. As far as a storyline I am sure I will have one but with all of this development on the framework I have had no time to even think about a storyline. But, I am open to ideas if anyone here has played SubSpace or a similar game. ;) |
| ||
| 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 #40) 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. |
| ||
 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. |
| ||
| 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. |
| ||
| Looks awesome! Does it work on iOS? |
| ||
| There seems to be a slight delay when you adjust the GUI windows ... think this is an touchscreen-input-issue (delayed recognition of "what touch event happened"). @ planet in the background Dunno how "far" the background planet is planned to be - for now it looks as if you are watching from another planets orbit - surrounded by wreckage and asteroids. If the intention is, that there is garbage all around the space, than there need to be very small objects right in front of the "background planet". For now it looks like this - planet - a big pile of nothing (the planet does not move, so it is really far away - and this means, it is super-huge) - wreckage - ship - point of view So I do not know if the BG changes somewhen (or if you ever fly around near a huge planet or "solar system"). What I mean is, that the current "scenery" looks as if everything happens between "background planet" and "location of the spectator") - sorry if I am not able to really express I want to describe. @ shots (again) Did they de-accelerate when the ship stops (right before they collide with the asteroids)? @low-end walmart android Resolution? (think this is important, with "full hd" or better being more ressource hungry). bye Ron |
| ||
| Looks awesome! Does it work on iOS? Thanks. :) I imagine it will with no problems. Looking for an IPad to test on. All of the code is native Monkey and should compile for IOS. @Derron - I am just testing out the gaming framework so I am using the assets I have around to test. But I will improve the look as I go and includes thing like perspective and alike. The bullets/lasers are inertia based so the speed/angle/momentum of the ship effects the bullet speed/direction. The resolution is 1366x768 and the game is set to 1280x720 and will stretch to fit a given display. I can't relay enough how low end this tablet is made by RCA. It struggles with input (delay) and graphics processing. Really this is aimed at something like an Nvidia Shield tablet (or similar), but the fact it runs on my low end tablet is a good sign of performance. |
| ||
| I like the graphics. It's not real-world-physics like Derron expects it to be - it's just a (science-fiction) game. Looks good, in my opinion. |
| ||
| I do not expect "real-world-physics" - but a wrong parallax scrolling can ruin the whole "immersion". The only benefit we have in Sci-Fi is: everything is possible (the planet moves too...for whatever reason always in the opposite direction of the player ship). Imagine you have a game with a fight on a old train (cowboy-game, north vs south on the NES-like consoles/computers era): as you know a bit, how fast cars and trains (not the uber-fast modern ones) move, you know how the background should move with a camera being fixed to a player character on this train. You know: a bush right behind the train scrolls with "- trainspeed" but the more distance is between object and camera, the less it scrolls. I am really sure, that there is some kind of formula on how "fast" it has to move (either fixed on "Z", useable for really far away objects, or by calculating the real-world-dimension of an object - and the distance to the player/pov). Maybe this helps a bit as it shows one possible approach: http://www.platformmasters.com/parallax.shtml Next to this "mathematical thingy" there is another reason for a focus on backgrounds and parallax: While the rendererings of the space stations (in the background) look nice, they have a big problem, when used as "very near to the player ship" background layers: they do not change. So they were rendered with a fixed "camera setup" or "perspective". The nearer you are to an object, the more the to element's look should change (things should get hidden by nearer portions of the element, some others should get exposed. This is normally not obvious for "cartoon sprites" (which is why parallax works that nice there) but the more "realistic" things get (with baked shadow/lightning in the image) the more your eyes and brain will recognize the whole thing as being "faked". I do not have an idea how to circumvent this problem now (except putting many things "far away" - or to have multi-angle-renderings of all sprites). Again to "expecting real-world-physics": _I_ do not expect something from _your_ game/engine - it is _your_ child and it is up to you to decide what and when and how things happen. I am just trying to express my thoughts on this - with the potential possibility to help your project to improve. @ 1280x720 Do you use batch sprite optimization or so (minimizing texture switches) or sprite atlases (doing the same)? Especially with many GUI-elements (and stretchable 9patch-sprites + Text [even Bitmapfont-text to save on texture switches]) I see framerating being limited a bit in BlitzMax/myEngine/myGame. Am not knowing about the performance of my game on android, but think Brucey once stated it run on his mobile device once he introduced "polledInput"-adjustments (I stored all key-states on each update, "KeyHit()" etc. polled the system each time, resulting in low performance on that mobile device) I saw that your tablet uses software keys (that "buttons" on the bottom for "back", "context menu", "volume") - I saw that some apps are able to remove them or to style that background - this might allow more screen occupation but honestly: no clue how to achieve that now. @Performance If you add "sound", make sure you do not load the music as wav into it (memory) - think Monkey offloads its work to the "mediaplayer" library. For BMX-NG you might better play a bit with "bah.mod/soLoud.mod" and "streams" as the default SDL-audio-module only allows for a single stream. I know, audio is not a matter for you now - but somewhen this is included too. I know that I repeat myself over and over but I do not know whether you have read my posts in other threads too: Do not get me wrong when only writing about things "to improve" or "looking odd imho". It is easy to write "looks nice", "gorgeous graphics", "well done" - but this only improves on motivation (which should nonetheless be high if you do things "for joy and fun"). To improve the project, people should come up with some kind of feedback. As I can only judge from looking at the screens/vids I am kind of limited to visual or logical-related feedback. bye Ron |
| ||
| 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. |
| ||
| Looks cool.. but it looks pretty hard to till what objects are in the same plane as the ship. |
| ||
| ^This is due in part to each object looking similar as there are only basically two types of asteroids scaled to different sizes. I will get a hold of some more asteroid images which should help in visual separation. Also all of them basically have the same color which is a problem. I'm working on a new map ATM which I think will solve these issues. I do though think the parallax part is close as far as movement and depth. |
| ||
| 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... |
| ||
| Color/darken of the asteroids helps a bit already. Am not sure if the asteroids already have collision hulls for a more "3Dish" effect (for hills and slopes on the asteroid)... for crashing ships and bullets. Bye Ron |
   |