Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411283 Posts in 69325 Topics- by 58380 Members - Latest Member: bob1029

March 28, 2024, 11:47:42 PM

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 ... 295
Print
Author Topic: The grumpy old programmer room  (Read 733393 times)
oahda
Level 10
*****



View Profile
« Reply #5760 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
Administrator
Level 10
******



View Profile WWW
« Reply #5761 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

oahda
Level 10
*****



View Profile
« Reply #5762 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 3
***



View Profile
« Reply #5763 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.
The Tribute Of Legends Devlog Co-op zelda.
EmptyEpsilon Free Co-op multiplayer spaceship simulator
Daid
Level 3
***



View Profile
« Reply #5764 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.
The Tribute Of Legends Devlog Co-op zelda.
EmptyEpsilon Free Co-op multiplayer spaceship simulator
oahda
Level 10
*****



View Profile
« Reply #5765 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 #5766 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

nova++
Level 4
****


Real life space alien (not fake)


View Profile
« Reply #5767 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 #5768 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 6
*


View Profile WWW
« Reply #5769 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 3
***



View Profile
« Reply #5770 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.
The Tribute Of Legends Devlog Co-op zelda.
EmptyEpsilon Free Co-op multiplayer spaceship simulator
ProgramGamer
Administrator
Level 10
******


aka Mireille


View Profile
« Reply #5771 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 #5772 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 6
*


View Profile WWW
« Reply #5773 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
« Reply #5774 on: August 26, 2019, 08:11:44 AM »

What about using an open source engine?
Logged

fluffrabbit
Guest
« Reply #5775 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
Administrator
Level 10
******



View Profile WWW
« Reply #5776 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

oahda
Level 10
*****



View Profile
« Reply #5777 on: August 26, 2019, 09:59:42 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.

Yeah, I think they killed the old "Blender render" and its associated material system in favour of Cycles and Eevee.

I believe there are weekly streams on the Blender YouTube channel where they address questions posted on http://blender.today on the thread they make for each stream. Maybe you can bring it up there and see what they have to say if they have time to get around to it (they just ended their stream for this week about an hour ago so I think it's on Mondays).
Logged

gimymblert
Level 10
*****


The archivest master, leader of all documents


View Profile
« Reply #5778 on: August 26, 2019, 11:19:19 AM »

Good damn, thanks for warning me, unity and lender break stuff all the time anyway, that's why I'm still prototyping on blender, at least it's stable with known limitation.

Also I'm stuck on finding an efficient method of updating terrain, I like the "circular buffer/sliding windows" method of updating, but it doesn't seem to work well with LOD, because smaller mesh update (spatially) faster than bigger, the end up overlapping, I haven't found a cool solution that don't involve rebuilding entire mesh at LOD distance.
Logged

qMopey
Level 6
*


View Profile WWW
« Reply #5779 on: August 26, 2019, 12:48:02 PM »

What about using an open source engine?

They all use big dependencies, and it’s mostly back to square one for me at that point.
Logged
Pages: 1 ... 287 288 [289] 290 291 ... 295
Print
Jump to:  

Theme orange-lt created by panic