• Content count

  • Joined

  • Last visited

Community Reputation

1275 Excellent


About lawnjelly

  • Rank

Personal Information

  1. This will be a short technical one for anyone else facing the same problem. I can't pretend to have a clue what I was doing here, only the procedure I followed in the hope it will help others, I found little information online on this subject. I am writing an Android game and want to put in gamepad support, for analogue controllers. This had proved incredibly difficult, because the Android Studio emulator has no built in support for trying out gamepad functionality. So I had bought a Tronsmart Mars G02 wireless gamepad (comes with a usb wireless dongle). It also supports bluetooth. The problem I faced was that the gamepad worked fine on my Android tv box device, but wasn't working under Linux Mint, let alone in the emulator, and wasn't working via bluetooth on my tablet and phone. I needed it working in the emulator ideally to be able to debug (as the Android tv box was too far). Here is how I solved it, for anyone else facing the same problem. Firstly the problem of getting the gamepad working and seen under linux, and then the separate problem of getting it seen under the Android emulator (this may work under Windows too). Under Linux Unfortunately I couldn't get the bluetooth working as I didn't have up to date bluetooth, and none of my devices were seeing the gamepad. I plugged in the usb wireless dongle but no joy. It turns out the way to find out what is going on with usb devices is to use the command: lsusb This gives a list of devices attached, along with a vendor id and device id (takes the form 20bc:5500). It was identifying my dongle as an Xbox 360 controller. Yay! That was something at least, so I installed an xbox 360 gamepad driver by using: sudo apt-get install xboxdrv sudo xboxdrv --detach-kernel-driver It still didn't seem to do anything, but I needed to test whether it worked so I installed a joystick test app, 'jstest-gtk' using apt-get. The xbox gamepad showed up but didn't respond. Then I realised I had read in the gamepad manual I might have to switch the controller mode for PC from D-input mode to X-input. I did this and it appeared as a PS3 controller (with a different USB id), and it was working in the jstest app!! Under Android Emulator Next stage was to get it working in the Emulator. I gather the emulator used with Android Studio is qemu and I found this article: I followed the instructions here, basically: Navigate to emulator directory in the android sdk. Then to run it from command line: ./emulator -avd YOUR_VM -qemu -usb -usbdevice host:1234:abcd where the host is your usb vendor and id from lsusb command. This doesn't work straight off, you need to give it a udev rule to be able to talk to the usb port. I think this gives it permission, I'm not sure. Navigate to etc/udev/rules.d folder You will need to create a file in there with your rules. You will need root privileges for this (choose to open the folder as root in Nemo or use the appropriate method for your OS). I created a file called '10-local.rules' following the article. In this I inserted the udev rule suggested in the stackoverflow article: SUBSYSTEM!="usb", GOTO="end_skip_usb" ATTRS{idVendor}=="2563", ATTRS{idProduct}=="0575", TAG+="uaccess" LABEL="end_skip_usb" SUBSYSTEM!="usb", GOTO="end_skip_usb" ATTRS{idVendor}=="20bc", ATTRS{idProduct}=="5500", TAG+="uaccess" LABEL="end_skip_usb" Note that I actually put in two sets of rules because the usb vendor ID seemed to change once I had the emulator running, it originally gave me an UNKNOWN USB DEVICE error or some such in the emulator, so watch that the usb ID has not changed. I suspect only the latter one was needed in the end. To get the udev rules 'refreshed', I unplugged and replugged the usb dongle. This may be necessary. Once all this was done, and the emulator was 'cold booted' (you may need to wipe the data first for it to work) the emulator started, connected to the usb gamepad, and it worked! This whole procedure was a bit daunting for me as a linux newbie, but if at first you don't succeed keep trying and googling. Because the usb device is simply passed to the emulator, the first step getting it recognised by linux itself may not be necessary, I'm not sure. And a modified version of the technique may work for getting a gamepad working under windows.
  2. Over-ambitious projects

    Very good input from all of you guys. Agree there's a lot of Dunning-Krueger going on. There also seems to be an element of that child-like 'mine is going to be better than yours' effect. I don't know whether this is something we are born with, or something our parents / schools instil in us, the need to be 'better' and impress. Certainly not all people have it to the same extent. I have a sneaking suspicion it is something encouraged more in male children than female children, I anecdotally have heard more often males express belief that they will be 'the best footballer' or whatever. I guess society tends to reward and respect those who are better, and there can be ridicule (particularly for kids) when they are not good at something. There is also an element of many parents often saying to their kids 'you are the greatest', so the kids end up subconsciously primed to believe that they are better than average. Overall I don't think this competitive 'need to be better' is a bad thing, it has probably helped lead to many of mankind's advances. But there can be negative consequences too (sometimes catastrophic) so important to keep some kind of perspective.
  3. 2018 Challenge Missile Command

    You were right I ran ldd on it and it said I had everything except SDL2_ttf mix and image. It might even be possible to static link SDL2 (when not making it as a package with dependencies)? (sorryI am linux noob lol )
  4. 2018 Challenge Missile Command

    Was good. I tried it under my linux mint but it didn't seem to run, maybe some dependencies I didn't have (there are a load of dlls for the windows version)? But it ran fine under wine.
  5. Over-ambitious projects

    A psychology question really .. what is it about game development in particular that makes the typical first posts of a beginner something like: 'For my first game, I want to make one like this, that took 50 programmers, artists, and designers 3 years to make, but mine will be better, obviously and like, twice as big. I don't know any programming languages or how to make art. I'm thinking of using Unity, and I expect to finish it in 2 weeks. How should I begin?'. Not just beginners, more experienced developers and teams regularly fall into the same traps (and myself all the time ). I just can't imagine for example, on a forum for builders, first posts like 'Hi, for my first building, I'm thinking of making one like the Taj Mahal, only twice as big and impressive. I don't know how to lay bricks. How should I start?'. Or in music composition 'Hi, for my first composition, I'm thinking of making one like Moonlight Sonata, only much more impressive. I can't play the piano. How do I start?'. Why do we do this?
  6. New Player Movement

    Code wise.. in terms of most jumps won't exactly hit the ledge at hand height, but you still want them to succeed.
  7. New Player Movement

    Looks good! How do you manage the grab / hanging bit?
  8. Android Build and Performance

    For the D pad I was trying to cover myself in case I missed something obvious in the emulator. It seems an oversight to miss out on emulating a gamepad, it can't be that difficult to do, compared to say the accelerometers etc. The drivers I was referring to was when I was initially using my Cat B15 phone on windows I seem to remember downloading and installing specific adb driver to get it to work, as the universal adb driver didn't seem to play ball. No idea of whether it was absolutely necessary, as this was a few years ago. e.g. (
  9. Android Build and Performance

    In the last few weeks I've been focusing on getting the Android build of my jungle game working and tested. Last time I did this I was working from Windows, but now I've totally migrated to Linux I wasn't sure how easily everything would go. In the end, it turns out that support for Linux is great, in fact it was easier than getting things up and running on Windows, no special drivers needed. Definitely Android studio and particularly the emulators seem to be better than last time, with x86 emulators running near native speed, and much quicker APK uploads to the emulators (although still slow to the devices, I gather I can increase this by updating them to high Android version but then less good for testing). My devices I have at home are an old Cat B15 phone, 800x480 with a GPU that seems to date from 2006(!), a Nexus 7 2012 tablet, and finally an Amlogic S905X TV media player (2017). Funnily enough the TV box has been the most involved to get working. CPU issues My first issue to contend with was I got a 'SIGBUS illegal alignment' error when running on the phone. After tracking it down, it turns out the particular Arm CPU is very picky about the alignment of data. It is usually good practice to keep structures aligned well, but the x86 is very forgiving, and I use quite a few structs #pragma packed to 1 byte, particularly in serialization. Some padding in the structures sorted this. Next I had spent many hours trying to figure out a strange bug whereby the object lighting worked fine on emulators, but looked wrong on the device. I had a suspicion it was a signed / unsigned issue in values for diffuse light in a shader input, but I couldn't see anything wrong with the code. Almost unbelievably, when I tracked it down, it turned there wasn't anything wrong with the code. The problem was that on the x86 compiler, a 'char' defaults to be a signed char, but on the ARM compiler, 'char' defaults to unsigned!! This is an interesting choice (apparently on the ARM chip the unsigned may be faster) but it goes against the usual convention for short, int etc. It was easy enough to fix by flipping a compiler switch. I guess I should really be using explicit signed / unsigned types. It has always struck me as somewhat wierd that C is so vague with the in-built types, with number of bits and the sign, given that changing these usually gives bugs. GPU issues The biggest problem I tend to have with OpenGL ES devices is the 'precision' specifiers in shaders. You can fill them however you want on the desktop, but it just ignores them and uses high precision. However different devices have different capabilities for lowp, mediump and highp both in vertex and fragment shaders. What would be really helpful if the guys making the emulators / OpenGL ES on the desktop could allow it to emulate the lower precision, allowing us to debug precision on the desktop. Alas no, I couldn't figure out a way to get this to work. It may be impossible using the hardware OpenGL ES, but the emulator also can use SwiftShader so maybe they could implement this? My biggest problems were that my worst performing device for precision was actually my newest, the TV box. It is built for super fast decoding video at high resolution, but the fragment shaders are a minimal 10 bit precision affair, and the fill rate is poor for a 1080P device. This was coupled with the problem I couldn't usb connect up to the desktop for debugging, I literally was compiling an APK, putting it on a usb stick (or dropbox), taking to bedroom, installing, running. This is not ideal and I will look into either seeing if ADB will run over my LAN or getting another low precision device for testing. I won't go into detail on the precision issues, I wrote more on this on a post here: As a quick summary, 10 bits of precision in the fragment shader can lead to sampling error in any maths done there, especially in texture coordinate math. I was able to fix some of my problems by moving the tex coordinate calculations to the vertex shader, which has more precision. Then, it turns out that my TV box (and presumably many such chipsets) support an extra high precision path in the fragment shader, *as long as you don't touch the input data*. This allows them to do accurate uv coords on large texture maps, because they don't use the 10 bit precision. Menus I've written a rudimentary menu system for the game, with tickboxes, sliders and listboxes. This has enabled me to put in a bunch of debugging features I can turn on and off on devices, to try and find out what affects performance, without recompiling. Another trick from my console days is I have put in some simple graphical performance bars. I record the last 60 frames into a circle buffer and store things like the frame duration, and when certain game tasks took place. In my case the big issue is when a 'scroll' event takes place, as I render horizontal and vertical tiles of the landscape as you move about it. In the diagram the blue bar is where a scroll happens, a green bar is where the ground scroll happens, and the red is the frame duration. It doesn't show much on the desktop as the GPU is fast, but on the slow devices I often get a dropped frame on the scrolls, so I am trying to reduce this. I can turn on and off various aspects of the scrolling / rendering to track down what causes performance issues. Certainly PCF shadows are a big ask on mobiles, as is the ground (terrain) shader. On my first incarnation of the game I pre-rendered everything (graphics + shadows) out to a massive texture at loadup and just scrolled through it as you moved. This is great for performance, but unfortunately uses a shedload of memory if you want big maps. And phones don't have lots of memory. So a lot of technical effort has gone into writing the scrolling system which redraws the background in horizontal and vertical tiles as you move about. This is much more tricky with an angled landscape than with a top-down 90 degree view, and even more tricky when you have to render shadow maps as you move. Having identified the shadow map pass as being a bottleneck, I did some quick calculations for my max map size (approx 16384x16384) and decided that I could probably get away with pre-rendering the shadow map to a 2048x2048 texture. Alright it isn't very high resolution, but it beats turning shadows off completely. This is working fine, and avoids a lot of ugly issues from scrolling the shadow map. To render out the shadow map I render a bunch of 256x256 tiles and copy them to the final shadowmap. This fixed some of the slowness, then I realised I could go a step further. Much of the PCF shadows slowdown was from rendering the landscape shadows. The buildings and objects are much rarer so I figured I could pre-render a low-res landscape shadow texture, and use this when scrolling, then only need to do expensive PCF / simple shadows on the static objects, and dynamic objects. This worked a treat, and incidentally solves at a stroke precision issues I was having with the shadow shader on the 10 bit hardware. Joysticks As well as supporting touchscreens and keyboards, I want to support gamepads, so I bought a bluetooth / wireless gamepad for xmas. It works great with the TV box with wireless dongle, unfortunately, the bluetooth doesn't seem to work with my old phone and tablet, or my desktop. So it has been very difficult / impossible to debug to get analog joystick working. And, in an oversight(?) for the emulator, there doesn't seem to be an option for emulating a gamepad. I can get a D pad but I don't think it is analog. So after some stabs in the dark with docs I am still facing gamepad focus issues so will have to wait till I have a suitable device to debug this. That's all for now folks!
  10. I'm interested in rendering a grayscale output from a shader, to save into a texture for later use. I only want an 1 channel 8 bit texture rather than RGBA, to save memory etc. I can think of a number of possible ways of doing this in OpenGL off the top of my head, just wondering what you guys think is the best / easiest / most compatible way, before I dive into coding? This has to work on old android OpenGL ES2 phones / tablets etc, so nothing too funky. Is there some way of rendering to a normal RGBA frame buffer, then using glCopyTexSubImage2D or similar to copy + translate the RGBA to a grayscale texture? This would seem the most obvious, and the docs kind of suggest it might work. Creating an 8 bit framebuffer. If this is possible / a good option? Rendering out RGBA, using glReadPixels, translating on the CPU to grayscale then reuploading as a fresh texture. Slow and horrible but this is a preprocess, and would be a good option is this is more guaranteed to work than other methods.
  11. The Rework Begins

    This licence as you state it sounds very dodgy, it might be worth double checking with a lawyer. It sounds reasonable to have a licence not allowing you to use the program for commercial work, and to be able to come after you for infringement for using it unlicensed. However, to claim any sort of ownership / rights over what you have created sounds ridiculous. It would be like stealing a pen, and writing a best selling novel on it, then the pen owner coming after you to sue for the profits from the novel, rather than for the crime of stealing the pen. Companies often write all sorts of ridiculous requirements on their EULAs, many of which they know full well are unenforceable. I myself ran a website a while back which required a pledge of allegiance to Adolf Hitler.
  12. Providing you aren't having a problem in practice with your IDs, there is no problem in using it. In some cases using callbacks / enums / strings etc can be overengineering. But it totally depends on how many popups you are dealing with, and the use case. If it starts with 3 popups, then you find you are using it more than you first envisaged and you become more likely to make mistakes with ID collisions etc. If there are only a few canned 'actions' in response to the selections, it may make sense to store these on the GUI object and make it 'self aware' rather than deal with lots of similar case statements.
  13. Want to buy an Asus laptop ? Think before.

    From this article It suggests you should be able to demand a refund from the seller, without having to justify. Whether the french retailer takes any notice of french law or EU directives is another matter. I am familiar with the frustration, I remember asking earlier this year at a tech company for the nearest internet cafe, and being told, 'this is france, monsieur' with a gallic shrug. While I don't excuse you getting a laptop that blew up, the current tech business is built on the principle of churning out lots of high volume. There will be a certain proportion of duds (perhaps even 10%), but it is cheaper to get these as returns than to do quality control in the factory. If they did proper quality control, the product would cost 2-3x as much, and they would go out of business. So in practice when you buy an electronic doodad, you need a quick and easy way of getting it exchanged. In the UK, if you get a dud, you fill out a form online, a courier comes to your door and collects the dud, and replaces it with a brand new replacement. There is no question of 'repair', it makes no economic sense, and reputation is important for retailers. The duds get dealt with by the retailer (perhaps sent back to the manufacturers, or just claimed for). Personally if you have something fry in a laptop, you will want the whole thing replaced as who knows how it will have affected the other components .. what if you want to resale it etc? You paid for a fresh new fully working laptop and that is what you should get. Definitely next time I'd be much more careful about picking a retailer. Even consider ordering from a big respected retailer in UK, Germany etc.
  14. what is the appeal of fps games?

    Rather answering the topic title rather than the specific question (which is down to things like whether you enjoy the particular rules, physics, graphics, gameplay, weapons): If you watch a cat play, they like to play hunting games. You can move a stick around and it engages its hunting instincts, and it gets to practice them in a safe way that very literally translates to something that could give it a survival advantage in finding the next meal / evading danger. So their survival skills are a combination of instincts and practice. Although we live in a modern world, biologically we are still cavemen that have evolved for millions of years having to hunt to survive, fight against enemy humans, run / hide from predators. There has been very strong selective pressure for these things, rather than the ability to walk to MacDonalds. So as in cat play there is probably brain reward (endorphins etc) from the same kind of practice activities in humans - running and hiding with a 1st person viewpoint, using weapons etc.. For the same kind of reasons. It better prepares us should we have to use these skills to survive in a real situation. It is no accident that soldiers play a lot of 1st person shooters. Some people morally disagree with the idea of shooting bad guys. But put that same person in the situation where they are getting chased by a sabre tooth tiger, they better have got some practice in first otherwise they are going to make a tasty snack.
  15. I was in the same boat previously: while most of my texturing was fine, on the problem hardware one of the textures in an offending shader looked to be being filtered incorrectly (as if it was using point filtering instead of linear). I had assumed my filtering states were wrong but on further investigation I now believe it is down to the precision in the texture coordinate calculations. The ARM articles suggest this, that on the most basic hardware calculated tex coords will have 10 bit precision (presumably a half float), and directly passed coordinates (which is far more common) get a fast 24p path. According to the specs I believe you could theoretically have hardware with only the 10 bit path (although texture filtering would look pretty bad). I actually pinned down the problem in another more complex terrain procedural shader where it was far more pronounced. I will know the answer soon as I am altering code to calculate the tex coords in the vertex shader, but have yet to try it on the offending hardware. Hopefully it will solve the problems. >> EDIT Confirmed. It was the precision. Moving the texture coordinate calculation into the vertex shader cured the 'filtering' issues on the TV box, as expected.