1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
  2. Dismiss Notice

Pyra Learning OpenGL ES 2.0 for Pyra

Discussion in 'OpenGL ES and GLSL ES' started by kaprikawn, Jan 14, 2018.

  1. kaprikawn

    kaprikawn Member

    Joined:
    Sep 28, 2008
    Messages:
    333
    Location:
    UK
    It's sorted now I think. Initialising the rotation variable to 0 instead of declaring it with no value seems to have fixed it so I think it's what I suspected.
     
  2. levi

    levi Still fresh, damnit!

    Joined:
    Oct 6, 2008
    Messages:
    8,901
    Location:
    Somewhere off the coast of the EU
    Ah, that makes sense. I still wonder why your code supports rotation about that axis at all, but I guess it came from the code you cribbed and inserted.

    Edit: Git pulled and run - yes, the ship is stable from the start now, and I can now observe without being distracted that the ship does indeed bank as you move left and right, so that's why the rotation and normalising code is needed. And I think it build most it not all of the source files, and the warnings seem to be gone, so thanks for that all round!
     
    Last edited: Apr 3, 2018
  3. kaprikawn

    kaprikawn Member

    Joined:
    Sep 28, 2008
    Messages:
    333
    Location:
    UK
  4. levi

    levi Still fresh, damnit!

    Joined:
    Oct 6, 2008
    Messages:
    8,901
    Location:
    Somewhere off the coast of the EU
    Nice, that version does seem to move around a lot faster on my old hardware now. Although now it's running so fast that it seems to be dropping some frames here - could I add vsync to this to slow it down?
     
  5. kaprikawn

    kaprikawn Member

    Joined:
    Sep 28, 2008
    Messages:
    333
    Location:
    UK
    That's odd, it is more efficient code, but at this stage pretty much any hardware should have been able to handle the inefficiencies from before. I'm running on a powerful computer, I'll maybe have to test on something a bit less capable like a Raspberry Pi.

    VSync is already enabled, or at least it should be. There's a chance it isn't because I cribbed that code from an old 2D project. In that you declare a SDL Renderer object and that's where you enable vsync. This object is used extensively when using 2D graphics, but here I'm instantiating it, but not using it after that. Maybe that means vsync isn't being applied?

    Regardless, there's frame limiting code in main.cpp which should stop the game running too fast so I don't know what's going on there. Maybe when I try it on the Raspberry Pi I'll be able to see what's going on.
     
  6. kaprikawn

    kaprikawn Member

    Joined:
    Sep 28, 2008
    Messages:
    333
    Location:
    UK
  7. levi

    levi Still fresh, damnit!

    Joined:
    Oct 6, 2008
    Messages:
    8,901
    Location:
    Somewhere off the coast of the EU
    Just tried it again, and it seems less choppy now. Maybe because I'm running it earlier in my session, my web browser hasn't decided to eat so much of the CPU yet, dunno. Now that I'm able to shoot, I note two things; one it tends to drift in the last direction moved. This may be a deliberate gameplay element, stopping you from overloading one spot and forcing you to continually adjust to succeed. The other is more concerning; if you're firing and you move, you stop firing until you hit the fire button again. It seems it's using text input style autorepeating to give the turbo fire effect and the continuous movement while you hold down an arrow yet; this doesn't seem ideal for a game, which I'd really expect more to be looking at the keyboard martix, and polling the fire button state for example. Maybe this works differently with a joystick - I've not pulled any of those out yet though.
     
  8. kaprikawn

    kaprikawn Member

    Joined:
    Sep 28, 2008
    Messages:
    333
    Location:
    UK
    Added another blog post :

    https://kaprikawn.wordpress.com/2018/04/16/learning-to-learn-opengl-es-2-0-part-19-were-moving/

    I've changed a call to OpenGL from once per frame to once at the start which may increase performance. But on the other hand I've just added a dirty hack to render a whole bunch of triangles without figuring out how many I actually needed for the floor. So performance could go either way with the latest commit. I'm planning to do a rewrite from scratch once I've got one or two complete levels working, I'm not too concered about performance right now.

    The drifting isn't intentional, I just need to figure out some better code to make the ship come to a standstill. Other options I've tried before have made the ship come to too abrupt a stop.
     
  9. levi

    levi Still fresh, damnit!

    Joined:
    Oct 6, 2008
    Messages:
    8,901
    Location:
    Somewhere off the coast of the EU
    Runs fine for me again on the latest tag version. I wonder if this could detect the screen size, because on the machine I'm currently running this on, the game window is significantly bigger than the available screen space I have. You haven't implemented all of the window furniture buttons, so I couldn't see what would happen if I tried to maximise it.

    I note also that you've no removed the hard barriers at the edge of the screen. It's quite easy to lose the ship now, so if you're planning to leave that in, I'd suggest you add arrows at the edges of the screen to indicate where your lost ship is, and how to get it back. I note that it's currently possible to disappear below the floor, so I guess it wasn't entirely intentional, but at least bullet occlusions with the floor all seem to be working :D
     
  10. kaprikawn

    kaprikawn Member

    Joined:
    Sep 28, 2008
    Messages:
    333
    Location:
    UK
    I've just had the week off, so I've rewrote all my code. I've added a fullscreen option which will run at your native resolution. To run it fullscreen, change fullscreen=0 to fullscreen=1 in the run file, or if you're running the exe file manually do
    Code:
    ./exe --fullscreen
    (I prefer using the run file because I've written in the GALLIUM_HUD parameters).

    I've also sorted out the vsync properly, so any stutter should be gone, I found it quite noticeable before and I'm not particularly bothered by stutter normally.

    Taking out the out-of-bounds limits was probably just me rewriting the velocity code and not reimplimenting it, I'll add it back in at come point. Probably when I do some work on the camera so that it moves. The only out-of-bounds code in there at the minute stops the target reticule going below the floor.

    New blog post is here:
    https://kaprikawn.wordpress.com/201...rn-opengl-es-2-0-part-20-collision-detection/

    Collsion detection has been added so the ship knows when it hits the arch.
     
  11. levi

    levi Still fresh, damnit!

    Joined:
    Oct 6, 2008
    Messages:
    8,901
    Location:
    Somewhere off the coast of the EU
    Hmm v0.3.0 runs like treacle for me. Luckily v0.3.1 runs a lot smoother somehow on this old netbook. Yes, --fullscreen works nicely on v0.3.1 also, and also I can no longer fly through the floor, which I could on all previous versions since you introduced the floor including v0.3.0. I'm not sure v0.3.1 is as fast as the old v0.2.x versions but it's doing a lot more so that's probably okay. Guess I shouldn't expect any final game to run well here though.

    FWIW, you seem to have switched to WASD controls rather than arrow keys. That's probably preferable for me, as I did initially wonder what was up with the controls until I finally tried the arrow keys, but it did produce an episode of the opposite confusion on this occasion!
     

Share This Page

Loading...