-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0|351|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
Socoder -> Off Topic -> AGAWFrame

Page : 1 2 3 4 5 6 7 Prev 8 9 Next
Posted : Saturday, 11 November 2017, 18:53
Jayenkai
Excellent.
Thanks again, HoboBen, and thanks RSKGames, too!
OK, looks like the Linux version is at least workable, and even if there may be quirks to poke and prod into submission, it's definitely good to know I can at least vaguely post Linux editions of things in the future.

Next up, iOS and Mac... Eeek!

-=-=-
''Load, Next List!''
Posted : Monday, 13 November 2017, 14:50
Jayenkai
Back to testing.

Not quite sure how OpenGL handles its draw routines, from a texture point of view, but it seems fairly well optimised when it comes to handling spritesheets.

Benchmark 2 (Windows only, for now) gives fairly interesting results.

Post benchmark results below, and tomorrow I'll explain why I think it's fascinating! (I might even make it its own thread)



-=-=-
''Load, Next List!''
Posted : Monday, 13 November 2017, 14:56
Dabz

Dabz

-=-=-
Intel Core i5 6400 2.7GHz, NVIDIA GeForce GTX 1070 (8GB), 8Gig DDR4 RAM, 256GB SSD, 1TB HDD, Windows 10 64bit
Posted : Monday, 13 November 2017, 15:00
Jayenkai
Epic!!!
Can you tell I'm running a shitty onboard Intel thing!

-=-=-
''Load, Next List!''
Posted : Monday, 13 November 2017, 15:08
GfK
Crikey... that took a while (shitty laptop, like before)


Posted : Monday, 13 November 2017, 15:41
rockford

Posted : Monday, 13 November 2017, 19:02
therevillsgames
Work PC:


Posted : Monday, 13 November 2017, 21:11
rskgames
Windows 8.1 nVidia 840m i5



-=-=-

Posted : Tuesday, 14 November 2017, 00:59
GfK
@steve - and i thought my results were bad! Does your work PC run on coal?
Posted : Tuesday, 14 November 2017, 03:48
steve_ancell

Posted : Tuesday, 14 November 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!''
Posted : Tuesday, 14 November 2017, 14:23
Jayenkai


MMMMmmm...
Checklist is happy!

-=-=-
''Load, Next List!''
Posted : Tuesday, 14 November 2017, 15:03
rockford
Cool, but you know that the last 20% allegedly takes 80% of the time to complete...
Posted : Tuesday, 14 November 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!''
Posted : Tuesday, 14 November 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!
Posted : Wednesday, 15 November 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!''
Posted : Thursday, 16 November 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!''
Posted : Thursday, 16 November 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!)

-=-=-

Posted : Friday, 17 November 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!''
Posted : Friday, 17 November 2017, 04:51
Jayenkai
"OK, Now to simply add online URL reading.."
...

..

OH FUCK!!!

-=-=-
''Load, Next List!''
Posted : Saturday, 18 November 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!''
Posted : Saturday, 18 November 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!''
Posted : Wednesday, 22 November 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!''
Posted : Wednesday, 22 November 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!''
Posted : Friday, 24 November 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!''
Page : 1 2 3 4 5 6 7 Prev 8 9 Next