Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1366136 Posts in 64012 Topics- by 55898 Members - Latest Member: obemef

September 17, 2019, 09:10:52 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)The grumpy old programmer room
Pages: 1 ... 287 288 [289] 290 291
Print
Author Topic: The grumpy old programmer room  (Read 603457 times)
Daid
Level 2
**



View Profile
« Reply #5760 on: July 01, 2019, 01:38:35 PM »

Well, found out I wasn't handling the SDL_QUIT event, that cause my first run of main to never exit. My S3 is a bit of an old phone, so maybe that's related as well.
https://developer.android.com/guide/components/activities/activity-lifecycle
I think it happens if the activity goes trough onStop and then to onRestart. I found a post on the SDL mailing list as well that this was expected behavior...

Now I just need to figure out why my OpenGL window has a different actual rendering size then SDL is reporting. Just applied the hack that I get the values from glGetInteger(GL_VIEWPORT) to get the rendering size instead of requesting it proper from SDL.
Logged

Software engineer by trade. Game development by hobby.
Prinsessa
Level 10
*****


Ava Skoog


View Profile WWW
« Reply #5761 on: July 01, 2019, 03:56:34 PM »

I wrote this way too long ago now to remember the specifics of it or how I learned about it, but I do have some special Android-specific code to get the dimensions after window creation in case it helps:

Code:
SDL_Rect rect;
SDL_GetDisplayBounds(0, &rect);

And then just rect.w and rect.h. Maybe the difference was that this accounts for the size of the bar with the Android software buttons or something?

In case you need that too, I also have this specific to iOS:

Code:
CGRect rect = [[UIScreen mainScreen] bounds];

With rect.size.width and so on, optionally multiplied by [UIScreen mainScreen].scale to account for retina.
                        
Logged

Daid
Level 2
**



View Profile
« Reply #5762 on: July 02, 2019, 10:32:53 AM »

Problem is, with SDL 2.0.9 (didn't check latest master yet) all functions, SDL_GetDisplayBounds, SDL_GetWindowSize, SDL_GetCurrentDisplayMode, SDL_GetDisplayUsableBounds, SDL_GetWindowSurface()->w/h report "720x1280".
I'm rendering with OpenGL ES, and the positioning of my rendering was off when I use glViewport.

SDL is also reporting (in logcat)
Code:
V/SDL     (27931): Window size: 640x1138
V/SDL     (27931): Device size: 720x1280
Of which the "Window size" seems to be the size of the OpenGL buffer that I'm getting to render on, but no way to get it from C or influence it properly so it matches the device size...
Logged

Software engineer by trade. Game development by hobby.
Prinsessa
Level 10
*****


Ava Skoog


View Profile WWW
« Reply #5763 on: July 03, 2019, 04:27:56 AM »

Hm... Wonder if I’ve just been lucky on the devices I’ve tried my app on and if I’d have the same issue on yours… Have you tested on other devices?
Logged

ThemsAllTook
Global Moderator
Level 10
******



View Profile WWW
« Reply #5764 on: July 03, 2019, 08:58:10 AM »

I remember having this problem too (without SDL; NativeActivity and JNI in my case), and I don't think I ever found a solution other than just hiding the status bar so that my GL viewport fills the whole screen. Android is really wonky about stuff like this.
Logged

Prinsessa
Level 10
*****


Ava Skoog


View Profile WWW
« Reply #5765 on: July 03, 2019, 11:08:08 AM »

Oh, if the issue is simply getting rid of the bar that tells the time and so on I think that might have been a setting in one of the XML files or something used for Android apps.

But yeah. Android is tricky. So many different devices and brands.
Logged

Daid
Level 2
**



View Profile
« Reply #5766 on: July 03, 2019, 01:02:26 PM »

Well, I don't want the status bar, so I'm in luck there :-), but I would expect SDL_GetDisplayUsableBounds to report the size without the status bar if your application is properly configured not to cover it.

Found my sizing issue. I didn't have a "uses-sdk" in my manifest file (normally gradle adds this apparently during the build process, but I avoid gradle at all costs) most likely this was triggering some compatibility mode for older apps.
Logged

Software engineer by trade. Game development by hobby.
Daid
Level 2
**



View Profile
« Reply #5767 on: July 06, 2019, 11:54:30 AM »

Well, found out 1 way to run "main()" multiple times with SDL2 and Android. If I return from the main function (because the user clicked "quit") and then he restarts the app, it runs main again without re-initializing the memory. Instead of returning from main() just calling exit() solves it, but using exit() in Android is apparently bad practice...
Logged

Software engineer by trade. Game development by hobby.
Prinsessa
Level 10
*****


Ava Skoog


View Profile WWW
« Reply #5768 on: July 07, 2019, 09:23:04 AM »

Looks like I'm going to have to do some more work on my Android code… I feel like there are so many things like this for Android that I don't have to think about for other platforms, heh.
Logged

diegzumillo
Level 10
*****


This avatar is so old I still have a some hair


View Profile WWW
« Reply #5769 on: August 24, 2019, 08:04:11 PM »

I'm trying to figure out which parts of my physics implementation are frame rate dependent and why. When I was coding it everything seemed obvious.

Anyway, Unity has a parameter for exactly that: Application.targetFrameRate. Apparently that doesn't work in the editor so it's useless to me. So I came up with this gloriously awful code

Code:
public int amount = 10;
   

    void Update()
    {
       
        GameObject blah = new GameObject("blaaah");
       
        for(int i =0; i<amount; i++){
            GameObject temp =Instantiate(blah);
            Destroy(temp);
        }
        DestroyImmediate(blah);
    }

Instantiation is huge a performance hog. So I just increase 'amount' to see what happens with a lower frame rate. This is the shortest stress test I could come up with. It's surprisingly hard to make a dent in the FPS with just pure math.

It works but it does not spark joy.
Logged

NovaSilisko
Level 2
**


Real life space alien (not fake)


View Profile
« Reply #5770 on: August 25, 2019, 02:26:18 PM »

Anyway, Unity has a parameter for exactly that: Application.targetFrameRate. Apparently that doesn't work in the editor so it's useless to me. So I came up with this gloriously awful code

Don't rely on targetFrameRate for this sort of stuff. All that's doing is telling the game what the FPS limiter should be at. Anything physics related you need to do in FixedUpdate(), set your desired fixed timestep in the Time project settings, and then use the Time.fixedDeltaTime variable for your delta (or define your own delta). If you're doing anything physics related in Update(), it will be framerate dependent. Yes, you can limit the framerate to make Update() be more consistent but... please don't

Or am I missing something? I find it a bit hard to believe you've programmed this insane space warping system yet never heard of FixedUpdate Tongue
Logged

diegzumillo
Level 10
*****


This avatar is so old I still have a some hair


View Profile WWW
« Reply #5771 on: August 25, 2019, 02:37:58 PM »

Anyway, Unity has a parameter for exactly that: Application.targetFrameRate. Apparently that doesn't work in the editor so it's useless to me. So I came up with this gloriously awful code

Don't rely on targetFrameRate for this sort of stuff. All that's doing is telling the game what the FPS limiter should be at. Anything physics related you need to do in FixedUpdate(), set your desired fixed timestep in the Time project settings, and then use the Time.fixedDeltaTime variable for your delta (or define your own delta). If you're doing anything physics related in Update(), it will be framerate dependent. Yes, you can limit the framerate to make Update() be more consistent but... please don't

Or am I missing something? I find it a bit hard to believe you've programmed this insane space warping system yet never heard of FixedUpdate Tongue

Never question my incompetence lol. But no, I am using fixedupdate; the issue is slightly more subtle. But not much. For the player controller I am using Update to process input but I was using fixedupdate to relay the results of the Update function to the physics simulation. And I was still seeing dependence of frame rate! I haven't quite figured out but there are some subtleties in the way one applies forces that I completely neglected so far. If one adds a force to the object, then at the end of the physics loop that force is zeroed out. Some things you want to immediately set it again, but not others. So what was happening is that the Update loop was setting the gravity, but if FPS dropped too much, then there would be several physics loops without gravity. While sometimes I would be applying a jump force throughout more than one physics loop, for example.

Logged

qMopey
Level 5
*****


View Profile WWW
« Reply #5772 on: August 25, 2019, 04:26:47 PM »

I’ll never understand how you guys can stomach the opaque nature of something like Unity. Not having source access and not understanding all the sources drives my crazy.
Logged
Daid
Level 2
**



View Profile
« Reply #5773 on: August 26, 2019, 03:36:55 AM »

I’ll never understand how you guys can stomach the opaque nature of something like Unity. Not having source access and not understanding all the sources drives my crazy.
I’ll never understand how you guys can stomach the opaque nature of something like the x86 CPU. Not having source access and not understanding all the sources drives my crazy.

I’ll never understand how you guys can stomach the opaque nature of something like the nano scale transistor logic. Not having source access and not understanding all the sources drives my crazy.

I’ll never understand how you guys can stomach the opaque nature of something like the universe. Not having source access and not understanding all the sources drives my crazy.



There is always a different level of deep you can dig, people accept different levels. Also, his problem had nothing to do with not understanding how Unity worked. He was searching for where he mis-used unity. AKA, I have the same problem with my home grown open-source game engine, where there is still a framerate depended part somewhere in a game, making the replays unstable. I have all the source, I understand how it works, but still these problems pop up.

Pushing like you do now qMopey hurt open-source more then they help it.
Logged

Software engineer by trade. Game development by hobby.
ProgramGamer
Administrator
Level 10
******


The programmer of games


View Profile
« Reply #5774 on: August 26, 2019, 03:40:17 AM »

Also, the Unity editor DOES have open source components, which are enough to dig in and understand what it's doing under the hood.
Logged

diegzumillo
Level 10
*****


This avatar is so old I still have a some hair


View Profile WWW
« Reply #5775 on: August 26, 2019, 04:07:56 AM »

I am always cursing at my limitations when using Unity. I'm sure I would be cursing at other limitations if I were doing things differently. Pros and cons to every approach.

However in this particular case I can't really blame unity at all. The physics engine is my own implementation and I realized I haven't thought through how to properly apply forces to objects. I'm using unity's Fixedupdate simply because it's a function that occurs at  fixed time intervals so I don't need to create my own.

edit: spelling

edit2: Actually, I just noticed what I shared in this topic has nothing to do with the actual physics bug, but an attempt at reducing frame rate with instantiation. I guess I can blame unity for not having a simpler way of achieving that.
« Last Edit: August 26, 2019, 04:21:46 AM by diegzumillo » Logged

qMopey
Level 5
*****


View Profile WWW
« Reply #5776 on: August 26, 2019, 07:08:57 AM »

Not really sure about pushing and hurting. That sounds far fetched. I’m just personally jealous of people who get by with all the frustration of not being able to solve their bugs via source ownership. I’d prefer not to write all this code I have here, and yet, due to preference I simply don’t have a choice  Beg

It’s not a matter of understanding all levels, but a matter of utility in solving bugs. I just really hate not being able to solve as many bugs as possible in a direct way. There are other benefits too, but bug solving is the biggest one.

Fundamentally I would rather spend extra time making my own software, so that I only have to learn high-level knowledge about code I personally own. What if Unity dies out? Or they deprecate something critical? What if I have a bug and just don’t know why it exists? What if I simply forgot to check mark this one thing within the Editor, hidden in some random UI element? I just can’t be bothered to memorize or worry about that stuff.

And now I’m doomed to make things slower than everyone using Unity. Wonderful :p
« Last Edit: August 26, 2019, 07:20:49 AM by qMopey » Logged
InfiniteStateMachine
Level 10
*****



View Profile WWW
« Reply #5777 on: August 26, 2019, 08:11:44 AM »

What about using an open source engine?
Logged

fluffrabbit
Level 2
**



View Profile WWW
« Reply #5778 on: August 26, 2019, 09:08:05 AM »

When people talk about Unity it sounds like word salad to me. But I would not recommend switching to an open source Unity clone like Godot, as they aren't very good. This is the programmer room, after all. Unity reduces C# to the role of a domain-specific scripting language, but if you really like C#, you should use it in the same way you use C++.
Logged

ThemsAllTook
Global Moderator
Level 10
******



View Profile WWW
« Reply #5779 on: August 26, 2019, 09:50:44 AM »

I've been doing a bunch of 3D work recently, and just got to a point where I'm pretty happy with my workflow. I've been using Blender 2.78, and decided that I'd like to try 2.80 since it has so many usability improvements. I was expecting a bit of a relearning curve, but what I got was a lot more of a problem... All of the textures and normal maps on my models are broken in 2.80 (with significant effort I found a way to get the textures back, but normal mapping is still a mystery), and some of the material properties I was using for lighting have been removed completely, breaking my model export script. Everything now seems to be geared exclusively for PBR, which isn't my preferred workflow. I'll have to either hack around this somehow, maybe involving another tool in the pipeline for modifying material properties since Blender lost the capability to do it, or rework my shaders and everything in a way I'm not sure I ultimately want to do in order to fit this new prescribed way of doing things.

A lot of the stuff in this program seems more heavily geared toward using it to produce renders all by itself, rather than creating mesh data suited for game development. The Python API documentation doesn't seem to have caught up yet, so I'll be blundering around in the dark if I want to fix my export script. Looks like I'll be sticking with 2.78 until they get some of this stuff sorted out, and I find a way to work around the stuff I was using that was removed.
Logged

Pages: 1 ... 287 288 [289] 290 291
Print
Jump to:  

Theme orange-lt created by panic