As it say on the page, thinking of data in C++ takes some time and some mental planning. Java with its quirks, I finally think I’ve got the knack of it.
Author Archive: csnorwood
WLGfx@home updated
Click here: WLGfx@home to view my PCs hosted site.
If it doesn’t load up then my home PC is not switched on.
There’s still quite a bit to do to this site, especially to do with the 3D stuff. I’ve got to setup a decent scene to show off with. Some cool shaders and some decent meshes.
Online GL shader editor
Just so I don’t lose or forget about it, I’ve found a very handy online openGL shader editor…
From basic shaders including texturing and lighting right up to procedural shaders and more.
All I need now is to run a sample project in Qt to test out some of these and then transfer them to GWT and Parallax. Good stuff can now be done.
Good and bad for embedded and Android
Embedded Linux is the bees knees for doing a lot of things, especially when you really don’t want the Android overhead on top of it. For a device such as the Odroid range which can be used as a headless server providing and IPTV gateway and a web interface for controls, linux is the better option.
When it comes to graphical applications, for example decoding video streams and openGL rendering, it always becomes a toss up between Linux and Android. A lot of people who are familiar with Java will automatically pick Java and I have to say, I do actually like the Java Virtual Machine. The JVM is handy whilst developing because a crashed application just gets cleared out.
Qt can also be used for developing mobile applications and has a very extensive framework and because it’s C++, time critical code isn’t a problem.
The only issue I have with Qt is that when it comes the day when I do want to release and application for whatever it is I finally do, packaging it up for all OS’s becomes a pain.
Qt for Android is easy, just build the project and get the APK. Just one file and it can be copied to any Adroid device.
Qt for Windows is a nuisance because you have to faff about with the terminal (which is awful in Windows) to package all the required libraries, and then it’s not guaranteed to run straight out of the box. For Windows you have to use a dependency walker to find the missing libraries.
Qt for Linux isn’t too bad unless you want the latest libraries. At this moment you can install Qt5.5 from the Linux repositories and away you go. Unfortunately, the latest version of Qt is 5.7 with some very nice additions so it’s back to packaging stuff up.
For embedded Linux it would have to be Qt from the Linux repositories.
For Android it is still a toss up between Qt and Android Studio + NDK. Although if I could get away with it I would use Qt and Linux unless it was going to be an application for the Android market.
Reinstallation done
All done and only got a few bits to install now. And the good news is that the tomcat server now works again.
Phew! I can get back to the 3D stuff again.
Re-install PC
I’ve recently upgraded from Linux Mint 17.3 to 18 and although everything else is working just fine, the tomcat server doesn’t. The client side of a web application works but there’s no joy from the server side so zero RPC calls are working.
A fresh install will be good anyway as it will clear a lot of junk out.
Ah well, should be about 30 minutes to an hour installing most of my software back. It’s handy having a nice 480Gb SSD and decent download speeds.
GWT + 3D
When my home server Apache is running (basically when my PC at home is on), then the very first test of 3D inside a web page is working…
However, the RPC calls are not working. I’ll get onto that straight away.
Eclipse update and GWT
After upgrading from Linux Mint 17.3 to 18, I found that the minimum Java available was 8. For GWT projects, up to 7 is allowed because there are issues running with Java 8.
So, I deleted Eclipse ready to install the latest. It installed fine. Still some issues along the way with Java 7 and 8 with GWT.
Eventually I installed Oracle Java 7. So far so good.
After finding that there is no longer support for Android in eclipse and installing all the Android stuff I cleared eclipse again. Actually I removed Eclipse a few times until I got Java 7 and 8 and all the GWT web stuff. Including Java EE version of eclipse.
Now I’ve figured out how to run a GWT project straight out of Eclipse without needing to upload onto the Apache server too. This makes for much faster build times. However, one cavaet is that I will have to create a linux group and add my user to the group next so that Tomcat7 and my user can read/write to the servers home directory.
Having sped up the build times, development of GWT projects will be so much easier and less time consuming. I will only need to deploy to the Apache main server when it has all been done. All I need to do is to save all files that I’ve been editing, click refresh in the server pane in Eclipse and go to the page in the browser. The browser will then tell the project to build itself the changes made.
Good stuff for a few hours of headaches.
LibGdx TextureAtlas (non .pack file)
Okay, I hit a block when I was starting to think about writing a quick networked multiplayer shoot em up game in LibGdx.
LibGdx texture atlas’s are very handy things because you can store a load of smaller images in one image. This also optimises the GPU draw routines because it doesn’t have to keep swapping textures for each sprite drawn.
I found pre-made free to use sprites from Kenney.nl, below is a section of what they look like:
Unfortunately though, LibGdx uses .pack files for it’s texture atlas’s and this one come with one that looks like this:
<TextureAtlas imagePath="sprites.png"> <SubTexture name="spaceAstronauts_001.png" x="998" y="847" width="34" height="44"/> <SubTexture name="spaceAstronauts_002.png" x="919" y="142" width="37" height="44"/> <SubTexture name="spaceAstronauts_003.png" x="824" y="0" width="50" height="44"/> ... </TextureAtlas>
Which is completely different to a .pack file.
So without further ado I decided to test out an xml parser to retrieve all the sub-regions from the xml file.
Test code as follows:
[snippet id=”19″]
So, armed with this now, all thanks mainly to working with GWT, I can quickly move on to creating my own class to generate the texture atlas in LibGdx.
TCP internet communication notes
Now that I’ve got that working over the internet, there are many things that this kind of thing can be used for. Most of them are obvious, but a few I’ve had in mind for some time now.
- For an app running on a device, it can download media specific to that device. ie, scaled to fit the resolution.
- A device can be checked for memory and storage space limits and then download media that is optimised for the device to run the app.
- Even for 3D apps, a device can request 3D meshes optimised to run on that device depending on the graphics capabilities. This can be useful for animated meshes with lots of vertices. The server can reduce the size of the mesh and the animation.
- If a device can output in surround sound then audio can requested that supports surround sound.
- Multiplayer games. The server can receive players positions and then send the local information back out to other devices.
- Devices can also send data to the server. This can be for a multitude of reasons. ie. a players profile picture or for audio communication between players.
As you can see from the above, there’s no limit to what a running server can do.
One thing I will have to do soon is to handle brute force attacks on the server. This happens when a DoS (Denial Of Service) attack occurs, which is a deliberate attack in which lots of data is sent to the server continuously. The simple way around this is to have a damn good fast CPU in the server and to record IP’s that are connecting. If an IP is not requesting the usual data and has attempted X amount of times then it goes onto a block list. Each connection attempt will first check the block list and instantly close the connection if that IP is blocked so that no further time is spent processing the connections request. At this current moment in time the Intel Xeon and the latest Intel i7’s have the cores that could handle DoS attacks.
Multiplayer games requires a whole new line of thinking, especially when they’re real time. Band width can be a pain, but there are many ways to get around this. In one of the above notes, I mentioned ‘local’ data. This comes into play when a players device only needs to receive the local updates in the surrounding area. Although the server will handle all players, it will only send each device its local data.
Anyway, that’s me done for now while I think of what to do next.
Any ideas, then get in touch.