Duke4.net Forums: gaula92 - Viewing Profile - Duke4.net Forums

Jump to content

Hide message Show message
Welcome to the Duke4.net Forums!

Register an account now to get access to all board features. After you've registered and logged in, you'll be able to create topics, post replies, send and receive private messages, disable the viewing of ads and more!

Reputation: 3 Neutral
Group:
Junior Members
Active Posts:
20 (0.05 per day)
Most Active In:
Everything EDuke32 (20 posts)
Joined:
12-September 16
Profile Views:
321
Last Active:
User is offline Nov 17 2017 05:55 AM
Currently:
Offline

My Information

Age:
Age Unknown
Birthday:
Birthday Unknown
Gender:
Not Telling Not Telling

Contact Information

E-mail:
Private

Posts I've Made

  1. In Topic: EDuke32 2.0 and Polymer!

    27 October 2017 - 02:32 AM

    View Postenderandrew, on 26 October 2017 - 05:42 PM, said:

    Wouldn't a software renderer not only put the main game logic on the CPU, but also all the renderering?

    And the Pi isn't a particularly strong CPU to begin with.



    That's not the case, since the CPU usage is not constant. Sometimes it's ~30% and others it's 100% of several cores. Something is going on.
  2. In Topic: EDuke32 2.0 and Polymer!

    26 October 2017 - 06:50 AM

    @Hendricks266: Do you have any idea on what could be using SO much CPU from time to time in Eduke32 on the PI? (In software mode)
    There's no better sourceport, and I'd like to see it running smoothly on the platform...
  3. In Topic: EDuke32 2.0 and Polymer!

    18 October 2017 - 05:06 PM

    @Hendricks266: I tried "vidmode 320 240", and alongside
    SDL_SetHint(SDL_HINT_RENDER_SCALE_QUALITY, "linear")
    before the SDL_CreateRenderer call, I get 320x240 frames being scaled up in hardwate to my monitor's full 1360x768 using SDL2 (which uses it's own GLES2 renderer).
    I think I understand what you say: the engine produces actual 640x480 frames, etc... so that's what the engine really renders, not an upscaling.

    However, even with as few pixels as 320x240, I can see some BIG peaks on CPU usage by the eduke32 process no other engine I have here shows on the Pi: CPU usage goes from 30% to 100% on several of the four cores! That's the cause of the hiccups. It doesn't seem to be scaling I guess, so I don't know what else to try.
  4. In Topic: EDuke32 2.0 and Polymer!

    18 October 2017 - 12:22 PM

    View PostHendricks266, on 18 October 2017 - 10:27 AM, said:

    Sounds like Polymost. I think it's something I'll be able to address fairly soon.

    I wonder, does Classic run any better if you run with `SDL_RENDER_DRIVER=software ./eduke32`? Or `export SDL_RENDER_DRIVER=software` in your terminal session before launching EDuke32.


    I have just tested that. The result is that the game appears unscaled on a coner of the screen (SDL2 on the Pi is NOT supposed to run on a desktop enviroment but on fullscreen framebuffer instead: SDL2 provides the 2D subsystems, an interface to dispmanx, for the SDL2 GLES renderer to draw on. NOT to be confused with the eduke3D GLES renderer).
    Other than that, it performs worse.

    Without that, the classic renderer works well but has hiccups: that's to be expected because it's using ~88% CPU according to TOP. That high CPU usage comes from the fact that eduke3d classic renderer renders 640x480 frames: a 320x200 or 320x240 video mode should exist so eduke3d would render the frames INTERNALLY at the original game's resolution, and then let SDL2 scale to fullscreen using it's GLES renderer.
    It's currently scaling the 640x480 frames, but it doesn't look as good as a 320x200 internal frame scaled to fullscreen physical resolution with a bilinear filter on it.
    A matter of taste I guess, but the 320 video modes would be more optima CPU-wise for platforms like the Pi: NO software scaling at all should be done on such systems.
    In fact, I seem to recall there was a 320x200 or 320x240 video mode time ago...

    Producing internal frames at original game's resolution AND letting SDL2 do the scaing in hardware is what other engines do, like SDLPoP (Prince of Persia open source clone), RAWGL (Another World) or GZDoom. This aproximation works great and guarantees low CPU usage and perfect framerates without hiccups.

    Also, if I set FULLSCREEN ON on the graphics menu, the APPLY CHANGES option is greyed out, as if eduke3d would be detecting (wrong) that the Pi is unable of fullscreen SDL2 window... but in fact it's the ONLY type of SDL2 window it supports! :D
  5. In Topic: EDuke32 2.0 and Polymer!

    18 October 2017 - 03:26 AM

    View PostHendricks266, on 17 October 2017 - 02:05 PM, said:

    Cool! Unfortunately our hardware accelerate graphics systems are all overdue for overhauls, including the texture manager. What happens if you `rm textures textures.cache` and enter `r_texcache 0` in EDuke32's console? `r_texcompr 0` might be something else to try.

    Polymer relies on a large set of GL 3.0+ features and GL extensions that are beyond the scope of jwzgles. Neither TerminX nor I have any experience in that level of graphics programming, or the GL or GL ES APIs. I would be surprised if a Pi or a smartphone could manage 10 fps running Polymer, anyway.


    Doing those brings no changes... The game starts fine, but it goes crazy after a while (when I get to the upper part of the cinema on the first map it's already full of strange phenomenoms).
    Anyway, this Polymost renderer uses A LOT of CPU, like a whole core at 100% all the time. Software renderer is way faster, it's 60FPS with uncapped framerate and vysnc on, but the only problem is that it's not totally smooth like, let's say, GZDoom in software mode with uncapped framerate and vsync on.

Friends

gaula92 hasn't added any friends yet.

Comments

gaula92 has no profile comments yet. Why not say hello?


All copyrights and trademarks are property of their respective owners. Yes, our forum uses cookies. © 2017 Voidpoint, LLC

Enter your sign in name and password


Sign in options