|
Socoder -> Off Topic -> AGAWFrame |
|
| Mon, 13 Nov 2017, 21:11 | |
|
rskgames |
Windows 8.1 nVidia 840m i5 |
| Tue, 14 Nov 2017, 00:59 | |
|
GfK |
@steve - and i thought my results were bad! Does your work PC run on coal? 
|
| Tue, 14 Nov 2017, 03:48 | |
steve_ancell
|
|
| Tue, 14 Nov 2017, 04:41 | |
Jayenkai
|
OK, here's why I find that interesting.. Sprites Size 1 and Sprites Size 4 are giving (for the most part) near-identical results, whilst Sprites Size 3 is vastly slower. Size 1 is a 256x256 texture with 32x32 sprites on it. Size 3 is a 1024x1024 texture drawn as a full image. Size 4 is a 1024x1024 texture with 32x32 sprites on it. When you draw using OpenGL, you always give it the full texture, and then give it texture co-ords for each vertex point. This means that even with a 32x32 sprite, it's still having to handle the 256/1024 pixel texture. Oddly, 1 and 4 are giving more or less similar results. Both are rendering from 32x32 chunks, even though the texture size is vastly different. This basically means that I can cram a boatload of tiny sprites onto a massive texture, and not have to worry about slowdown because the texture's so big. Essentially, imagine a huge 1024x1024 texture full of 8x8 sprites, and they all draw at the speed of single 8x8 textures. Conversely, having a single large 1024x1024 texture and trying to draw that onscreen is remarkably slow. Note that in the benchmark above, Sprite size 1,2 and 4 are drawn 5000 times per frame, whilst Sprite size 3 is only drawn 500 times per frame. And it's STILL infinitely slower. In general, the speed of drawing a texture seems to be dependent on how much of the texture has to be rendered. Even if you have a GIANT texture, if you only ask it to draw a tiny part of it, it'll render much quicker. I know this is probably "really bleedin' obvious, Jay!", but I found it interesting to learn exactly what's going on in the background, and learning to work around those kinds of quirks. I had considered drawing tiles to a larger texture/tilemap, then drawing that texture in one single call, but from the above it might end up being quicker to just render a screen full of little tiles. ... Fascinating!!! -=-=- ''Load, Next List!'' 
|
| Tue, 14 Nov 2017, 14:23 | |
|
Jayenkai
|
 MMMMmmm... Checklist is happy! -=-=- ''Load, Next List!''
|
| Tue, 14 Nov 2017, 15:03 | |
rockford
|
Cool, but you know that the last 20% allegedly takes 80% of the time to complete... 
|
| Tue, 14 Nov 2017, 15:21 | |
|
Jayenkai
|
For the Draw-Primitives? Yeah... It got up to 80% about a week ago, and hasn't been touched, since! Only Tri and Poly to add to the list, mind. Tri won't be hard, I can reuse literally half of the Quad code. Poly, though.. ... Might skip that one! -=-=- ''Load, Next List!''
|
| Tue, 14 Nov 2017, 16:49 | |
therevillsgames
|
 @steve - and i thought my results were bad! Does your work PC run on coal?  LOL! I use it to test my games (still using BMX for our major releases) and if they run well on that machine I call it good  And they do!
|
| Wed, 15 Nov 2017, 07:16 | |
|
Jayenkai
|
Voice in my head : "You can already load wave data, place the data into buffers, loop the waves, pitch the waves and set the volumes and things.. .. Why don't you just write your own MOD player?" SHUT UP, HEAD... -=-=- ''Load, Next List!''
|
| Thu, 16 Nov 2017, 16:59 | |
|
Jayenkai
|
*has to google whether radius is just to the middle or the whole way* ... Fuck, my memory's going!! -=-=- ''Load, Next List!''
|
| Thu, 16 Nov 2017, 21:54 | |
HoboBen
|
Some OpenGL tips that might be helpful. 1. Textures The huge texture thing is a super common optimisation. OpenGL will take 8192x8192 textures with no sweat, and prefers it to switching between textures (which is SLOW!!!). I doubt there's a machine left running that won't handle 2048x2048 at least You can see what OpenGL texture sizes are supported with this code I posted on SoCoder back in 2011! 2. Shapes When you talk about rendering Polygons, lines etc. Just in case this is what you mean, you DO NOT want to use the OpenGL primitives - they are hardly used, they're often implemented with driver bugs, they're not pixel perfect and they render differently on every device. You want to use GL_TRIANGLES and GL_TRIANGLE_STRIP exclusively. Even for rendering lines. Even curved lines. Make your quads two triangles. 3. Texture units This may just be a modern OpenGL feature. When I said OpenGL hates switching between textures, that doesn't mean you can't have more than one. It just means you can have a static number of textures that you use simultaneously without unloading or loading any. These are called OpenGL texture units, and you are not guaranteed to have more than one. Cheap cards support roughly 16 units. Mid-range 32. High-range over 60. This code is how you find out how many of these textures you can use at once. The texture units are given fancy hard-coded names like GL_TEXTURE0 GL_TEXTURE1 GL_TEXTURE2... Up to GL_TEXTURE31 (If you need more than 32 of these I don't know what happens!) -=-=- blog | work | code | more code |
| Fri, 17 Nov 2017, 03:19 | |
|
Jayenkai
|
Thanks! 1. Yeah. I think I’ll probably self-limit to 1024 textures, max. After years of using Monkey on various systems, there’s been oodles of texture based traps that I’ve learned to avoid. I could "probably" be ok with 2048, but I figure if I keep that as a "pushing it" limit, then I’ll probably be safe elsewhere. I could see that code being handy for generating textures and perhaps maps ingame, but by the point I’m running it, I’ve already drawn the spritesheets, so it won’t really be that handy for simply loading things.. which is a pain in the arse! Why can’t these things be standardised!!! 2. Yes, I’m sticking with GL Tri's. At the very beginning of this project, one of the first things I learned was that GL_Quad was being depreciated. .. because.. *shrugs* too useful? Everything's been done as Tri's, even my "plot" and "line" get converted to tris. I lazily haven’t bothered to add a Triangle function, which is ironic given the whole flaming thing uses triangles. As for Poly.. really not sure how to tackle those, numerically. I mean, drawing them is one thing. But storing "draw 150 sided polygon" into an array meant for quads, is a little taxing! 3. Multiple textures, shaders and basic 3D functionality will be something I’ll be tackling later on down the road. For now my aim is just to get the thing up and running. It shouldn’t be too hard to add additional features once that's done. .. I hope!! -=-=- ''Load, Next List!''
|
| Fri, 17 Nov 2017, 04:51 | |
|
Jayenkai
|
"OK, Now to simply add online URL reading.." ... .. OH FUCK!!! -=-=- ''Load, Next List!''
|
| Sat, 18 Nov 2017, 08:14 | |
|
Jayenkai
|
Spent the past couple of hours trying to get iOS compiling to work, again.. It whinged about NSStrings. It whinged about OpenAL. It whinged about File Access After a lot of tweaks, and a couple of hours' work, I *think* it’s now just whinging about OpenGL stuff, and how I’m trying to open a window, and that sort of thing. Need to rewrite the majority of the code from GLFW to GLES. This shit ain't easy. -=-=- ''Load, Next List!''
|
| Sat, 18 Nov 2017, 15:17 | |
|
Jayenkai
|
View on YouTube Loading Screen - Version 1. Blink and you'll miss it! In future I'll be adding some form of super-fast benchmarking into there, to decide things like maximum Particles and Stars and whatnot. For now though, it's nice and fast. -=-=- ''Load, Next List!''
|
| Wed, 22 Nov 2017, 01:46 | |
|
Jayenkai
|
 Wasted pretty much all day, yesterday, tackling this.. It's still not right, but it is indeed "right".. I'm not sure quite how to fix it! -=-=- ''Load, Next List!''
|
| Wed, 22 Nov 2017, 02:29 | |
|
Jayenkai
|
 Much better. Amazing what you can do when you sleep on a problem! I've added an extra offset "Fix_amount" parameter to a new Tri_Fix function. 0 is circular centered, whilst 0.5 center aligns it perfectly. Oddly, 0.5 doesn't quite look right, either. This is it at 0.25, and it "feels" more centered than it does at either 0 or 0.5.  You just know the Start button's going to be bouncing, now
-=-=- ''Load, Next List!''
|
| Fri, 24 Nov 2017, 11:47 | |
|
Jayenkai
|
Figured I'd try installing the Android SDK/NDK/Studio gubbins into one of my Ubuntu VirtualBox installations. Chose to use the Ubuntu64 installation, because it seems I'll be sticking with Ubuntu32 for most Linux compiles.. So.. You know.. Less quirkyness due to hundreds of SDKs being installed! Best to keep them separate. So, I opened up Ubuntu64, attempted to fumble my way through the installation process, and eventually got the SDK installed. Then it was a case of opening Android Studio up, and getting that to install cmake, the NDK stuff and that other thing .. LLVM or something!? Can't remember what it was called. It's near the top of the installer list!... If I'm honest, I'm not sure why I'm even installing it. One of the 100-or-so tutorials I've read had mentioned it needing installed, so.. Following orders! Anyhoo, I got that installed, and managed to figure out how to add an environmental path to Ubuntu. Rebooted, and .. Nope! Apparently, even though I asked Android Studio to install in home/Jayenkai/Documents/Android_SDK/ (or something), it instead chose to install in home/Android/SDK/ ... Which I think is the default, therefore ... it just bloody well ignored me!! So I rejigged the environmental path, rebooted again, and .. bingo..  It's doing something! That's a barebones "Hello World" example, and I can't yet run it. I need to continue reading the tutorial to get from there, to a working OpenGL .apk, and then from there to getting the framework up and running, as an .apk, on my Android Test Doohickey. But this is already more process than I've managed in Windows. So.. Um.. I guess, Hoorah for Linux!?! *shudders* -=-=- ''Load, Next List!''
|
| Fri, 24 Nov 2017, 15:40 | |
|
Jayenkai
|
Thing I'm struggling with, tonight. GLFW doesn't appear to let me render to "larger than the screen's resolution" canvases. eg, because my lappy's maximum is 1366x768, I can't render out to 1920x1080. That's a bit of a bummer. I might need to poke and prod to find a way around that. -=-=- ''Load, Next List!''
|
| Fri, 24 Nov 2017, 15:55 | |
|
rockford
|
GLBasic allows that, so there's something amiss somewhere, methinks.
|
| Fri, 24 Nov 2017, 16:04 | |
|
Jayenkai
|
Yeah, it seems to be one of those "not in the Modern version" functions that have been depreciated just to screw me over... I’m currently considering that "a good option" would be to get the Mac version up and running, since the MacMini's plugged into a HDMI 1080p Monitor. Might not be an easy task!! -=-=- ''Load, Next List!''
|
| Sun, 26 Nov 2017, 08:39 | |
|
Jayenkai
|
 OPTIONS - GETS! A bit wordy, but honestly, what else can you do!?! -=-=- ''Load, Next List!''
|
| Sun, 03 Dec 2017, 04:58 | |
|
Jayenkai
|
*sigh* OK, Mouse co-ords all redone so that they work when Overscan's in use. Shittons of maths to get that working, btw.. Additionally, I rejigged the scaling so that if the framework's running on an iPhoneX, the overscan kicks in at the top/left of the screen, to avoid "bumper" issues. -=-=- ''Load, Next List!''
|
| Sun, 03 Dec 2017, 12:39 | |
|
Jayenkai
|
Hmm.. my "every controller works together to all be player one" code doesn’t seem to be working very well in Linux. Will have to have a good nosey at that. -=-=- ''Load, Next List!''
|
| Sun, 03 Dec 2017, 14:45 | |
|
Jayenkai
|
Spent most of today looking at my controller code, and screaming at the damn X360 pad being inverted.. Why X360 pad!? WHY!?!? Anyhoo.. Controller test!! -=-=- Copy+Pasted from AGameAWeek -=-=- Time for another test. If you're bored, are running Windows, have a controller or two at hand, and want to help out, please give this test a run. Download the Test Here (Windows only, right now. Linux is.. ... Being Linux!) It currently only uses "Port 1", so whatever joystick/gamepad you want to test should be connected first, before running. Run the exe, hit start, then play about with buttons and whatnot. The button names onscreen should be approximately accurate, but if they're not, please do let me know what controller you're using. The two thumbsticks (if indeed your controller HAS thumbsticks) should show up in the right spot, and with the correct axis. If the Y Axis is wrong, again, be sure to let me know what controller you're using. DPad should also work, but I've had issues with DPad in the past!! Either way, tap, click and press away, and let me know how it goes. Thanks! -=-=- ''Load, Next List!''
|
| Tue, 05 Dec 2017, 12:37 | |
|
Jayenkai
|
"Winsock".... Spent today trying to fathom that, and attempt to get URL Data Requests to work. ..it’s kinda working. I can see all the data that the server's sending me, but the start of the reply is curiously mangled, for some reason. Threading and delays will probably help, *sigh* -=-=- ''Load, Next List!''
|
|
|
| |||
|
| ||||