Jump to content
  • Advertisement

drwuro

Member
  • Content Count

    13
  • Joined

  • Last visited

Community Reputation

105 Neutral

1 Follower

About drwuro

  • Rank
    Member

Personal Information

  • Website
  • Role
    Artist
    Game Designer
    Programmer
  • Interests
    Art
    Audio
    Business
    Design
    Programming

Social

  • Twitter
    drwuro

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. drwuro

    Pygame - alternatives?

    I have now done a different kind of testing. I have limited the game's FPS to 60 using pygame.Clock, and I have measured the duration from one frame to the next, which should be a very constant value in a perfect world. And if I would do this in a C++/SDL game, it would work too. However, in Pygame, I have the following results: 0.0159058570862 0.0160629749298 0.015741109848 0.0169258117676 0.0149910449982 I picked out some values just to show the variance. As you can see, the numbers range from 15 ms to 17 ms, in a quite unstable manner. This is what I am talking about. I hope now it's clearer.
  2. drwuro

    Pygame - alternatives?

    @Julie.chan It is exactly ONE iteration of the main loop. But every measurement shows exactly the same result. Because it is actually how I described: The game loop code takes very little time and thus on my machine the game has hundreds of FPS when running without limitation.
  3. drwuro

    Pygame - alternatives?

    ncalls tottime percall cumtime percall filename:lineno(function) 1 0.001 0.001 0.001 0.001 {pygame.display.flip} 1 0.001 0.001 0.001 0.001 {pygame.transform.scale} 16 0.001 0.000 0.001 0.000 {method 'blit' of 'pygame.Surface' objects} 2 0.000 0.000 0.000 0.000 {pygame.draw.rect} 1 0.000 0.000 0.001 0.001 gloomy.py:551(render) 1 0.000 0.000 0.002 0.002 __init__.py:275(flipBuffers) 9 0.000 0.000 0.000 0.000 __init__.py:832(drawText) 1 0.000 0.000 0.000 0.000 cProfile.py:79(print_stats) 4 0.000 0.000 0.000 0.000 gloomy.py:615(_renderCharacter) 1 0.000 0.000 0.000 0.000 pstats.py:62(__init__) 6 0.000 0.000 0.000 0.000 __init__.py:269(drawSprite) 1 0.000 0.000 0.000 0.000 pstats.py:106(load_stats) 1 0.000 0.000 0.000 0.000 pstats.py:84(init) 1 0.000 0.000 0.000 0.000 {isinstance} 1 0.000 0.000 0.000 0.000 cProfile.py:90(create_stats) 1 0.000 0.000 0.000 0.000 {method 'tick_busy_loop' of 'Clock' objects} 2 0.000 0.000 0.000 0.000 __init__.py:265(fillRect) 1 0.000 0.000 0.000 0.000 {method 'sort' of 'list' objects} 4 0.000 0.000 0.000 0.000 gloomy.py:203(isWalking) 1 0.000 0.000 0.000 0.000 __init__.py:194(clearScreen) 1 0.000 0.000 0.000 0.000 {time.time} 1 0.000 0.000 0.000 0.000 {len} 1 0.000 0.000 0.000 0.000 {hasattr} 1 0.000 0.000 0.000 0.000 {method 'disable' of '_lsprof.Profiler' objects} 60 function calls in 0.003 seconds
  4. drwuro

    Pygame - alternatives?

    I can and will do that. However, I have the feeling we're talking about different things here. I don't have performance issues or low framerates. I have the problem that the framerate is not rock-solid stable, it's a bit jittery. However that doesn't mean that the code is "slow" or whatever. I will still provide the data as soon as I can, so we can make sure that's not the problem.
  5. drwuro

    Pygame - alternatives?

    Of course I have tested this, otherwise I wouldn't say it. My games are retro pixel-style and they run with between 180 and 400 FPS on my system. My update calls and collision checks are certainly not the problem. However, when I limit such a game to 60 FPS using pygame.Clock, it will never be plain 60 but sometimes 58-59 and sometimes 61-62. There are times where sprites move smoothly (exactyl 1 pixel per frame) but sometimes it gets shaky and jittery in certain parts of the screen. It's no surprise to me however as VSync is not enabled and thus having a game with close-to-60 running on a monitor with exactly 60 Hz is of course going to yield this effect. As I said, re-coding the whole game in C++ with SDL helps, as I have done that. But I don't want to do that with every game I have, as I prefer to code in Python.
  6. drwuro

    Pygame - alternatives?

    Thanks for all your answers. @Julie.chan Well I'm fairly sure it's not because of floating point errors, as I usually try to avoid using floating point arithmetics for my stuff. I'm also not using "delta time" approaches, I have a fixed time step for my update methods. So for example the main character moves exactly 1 pixel per update. Also, the performance of my machine is high enough to handle much higher framerates, so my approach was to try to limit it to e.g. 60 FPS and also having 60 updates. However, it's not as stable as if I do the same in C++ (I once created a game prototype with a scrolling background in Python and then basically ported the whole thing over to C++ with SDL, and even though both games had basically the same framerate, the scrolling was far more smooth in the C++ version than in the Pygame version, which was jittering all the time). @Astrofra Well I'm looking for something 2D actually. @markypooch I haven't profiled yet but as I said I assume no performance issues. As far as I'd assume, the reason for this all might be that the main loop of my game is written in Python (because I have to write it myself), and in some other engines/frameworks such as Love2D, the main loop is probably written in the C/C++ part. But not sure if that's really the reason. But as I said, when I coded the same thing in both Pygame and C++, the C++ version was much smoother and much more stable, whereas the Pygame version jittered. Btw I have tried to use pygame.HWSURFACE but it seems like there happens no difference.
  7. drwuro

    Pygame - alternatives?

    Well the thing is, even if I use the "clock" functionality and try to make my code run at a stable 60 FPS, it sometimes has 59 FPS or 62 FPS or something like that. Apparently it's not possible to use VSync at all, neither on Linux nor on Windows. The code of the game itself is fast enough (without limitation it runs at 180 FPS or something like that), so that's not the reason here. Now the problem is, when there is a sprite moving smoothly from one side of the screen to the other (imagine a simple arcade-like game, nothing 3D or so), you will sometimes see it jitter around instead of floating smoothly one pixel at a time. And as far as I've read so far, there is no way to fix this when using Pygame, it simply has to be accepted.
  8. drwuro

    Pygame - alternatives?

    Hi there, thanks for your replies! Well, I've looked into Pyglet but as far as I remember, it uses "the real OpenGL", while the Raspberry Pi only supports OpenGL ES, so Pyglet games won't run on the Raspberyr Pi, which is something I'd rather have in my feature list. I might be wrong but I think I remember it that way. I haven't looked at Cocos2d yet, but I remember that it was quite well-known a few years ago. However, I just checked the specs and it seems like it's also based on Pyglet. I will have another look at my Raspberry Pi issue though, maybe it was something else. @Julie.chan I also downloaded your SGE engine just now, well as far as it's Pygame-only it won't solve my problems of course. You said you also have an PySDL2 version in the works, so what is your opinion about PySDL2 vs Pygame? Would it make sense in general to move on to PySDL2 instead of Pygame? Is PySDL2 something "solid" or is it something someone created in his spare time but now abandoned it? It's hard to tell sometimes, from just looking at websites and so on.
  9. drwuro

    Pygame - alternatives?

    Oh maybe one additional piece of information, I am mostly developing 2D-retro-style games with blocky graphics.
  10. Hi there, I love coding in Python and thus I have also used Pygame a lot. In general I love Pygame, because it works for the most part, and it's quite easy to use, and it runs on many platforms, including the Raspberry Pi. What I don't like about Pygame is that it seems like it's impossible to create rock-solid frame rates, which might have to do with the fact that it's still based on SDL1 and it seems like there is no option to turn VSync on. Also, SDL1 is quite old now and I'd prefer something more modern for various reasons. But it would be cool if it would also run on a Raspberry Pi (which doesn't support full OpenGL, meaning some libraries won't be an option). I've read about PySDL2, PySFML, also I've looked into Love2D which is of course Lua, but seems to be a widely used thing nowadays. But it's a bit hard to judge what's really well-supported and future-proof and so on. That's why I'm struggling a bit with deciding what to use in the future (or maybe just sticking to Pygame, despite its imperfections). Any suggestions?
  11. well the reason why i don't want to use ads is simply that i don't like them myself, and though it might sound like it in this thread, money and profit is not the single thing i am focusing on. i want to create the game exactly like i imagine it to be, without compromises. but after that, of course i'd still like to make it sell considerably well. i don't know if it will work out, of course :)
  12. @ smr: I know, but as I mentioned in my original post, I would have to re-write the whole engine now, and I'd prefer to finish the Android version soon instead of re-starting from scratch
  13. Hi,   I am currently working on a game for Android, because I have an Android phone. After a while of developing, I heard that iOS is a much better gaming platform, sales-wise. However, I don't want to do everything from scratch now, so I'd like to finish the Android version and who knows, in the future I might create an iOS port.   I'm just wondering if someone here has some experience with developing only for Android; is it also possible to earn money there*, or would you definitely recommend making an iOS version as soon as possible?   * the game will not have ads, it will only have an unlockable full version
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!