windows (testing) help wanted
BlitzMax Forums/BlitzMax Programming/windows (testing) help wanted
| ||
| OK, I've got an app designed on mac and compiled for windows: https://adamstrange.itch.io/tarogue It generally works fine, but on some people machines runs at about 0.1 speed. It is openGL based and NOT directX. I don't have windows version information on the 'slow' machines Can people give it a test and give the results. Windows version, etc I know that Matty had this issue, so give it another go and let me know :) |
| ||
| Hiya, I just tested on a Win7 x64 machine, with a geforce750 ( I can test on a Win10 x64 with a geforce650 after work ), technically it seemed ok and certainly wasn't running slow, it was nice and smooth. There are some hard edge lighting anomalies around the torch lights but I see that they are also present in the screenshots too. Seemed very smooth although there is some jittering of the knight character when the knight is jumping - it looked typical of some kind of rounding error where the value was oscillating between rounding up and down, either way it doesn't match up to the quality of the game and lets the game down. When moving the knight true horizontal or vertical, ie say with both up and left pressed then the knight is moving too fast compared with moving with one key pressed. Perhaps the movement vector needs a simple normalization to correct that? Or it may be deliberate? Personally I like where the game is heading as I loved the old 'Knight Lore' style games on the speccy. Please let us redefine the keys! I see that you do have config file so hopefully you have plans for it, or maybe I missed it :D So how much will you be selling the game for? and when will it be ready? :^) |
| ||
| Looks good and runs fine here Adam :-) |
| ||
| @col, on the start menu there is an 'options' where you can redefine keys and joypad ;) Game is free |
| ||
| Windows 7 Laptod. AMD turium x 64 Windows 32 1.6 mhz dual. Ram 2 Gigas. Ok, run perfect. |
| ||
| but on some people machines runs at about 0.1 speed. Flip 0 vs Flip 1 vs Flip -1 (aka: vsync based timing mechanism used?) @ movement think it should move slower too (you know ... a² + b² = c², so speed calculation should not be that problematic). @ linux build now you've got a Windows build, next step is a build for Linux (use a VM and installsome ubuntu 12.10 or 14.10 with LXDE or XFCE flavor - to keep it light). Compilation should be trouble free once you got the preparations done (libraries). bye Ron |
| ||
| @Adam Thanks! I'll have a go later when I get home. For free? Awesome and thank you! So this already the full finished game? :^) |
| ||
| Just wanted you to know that it works ok on Win10x64 too. A cool game that's well put together. Thanks! |
| ||
| mmm, Not sure which windows systems have the issue. doesn't seem to be a pattern. opengl maybe? |
| ||
| Like said: Vsync? Which "Flip X" do you use? How do you advance your animations: "X :+ dx * deltaTime" or "X :+ dx" every tick of a specific TTimer - or relying on this very same call only happening at the refresh rate of the monitor/screen (vsync)? bye Ron |
| ||
| Just saw this thread now. Will have to try on the work machine....finished work for the week have to wait until monday but will gladly try it out then if you havent resolved it. Sorry i dont normally check the blitzmax area very often. |
| ||
| Maybe I'm misremembering, but wasn't there some big slowdown issue relating to joypads/joysticks if one of them gets unplugged after the game gets launched? |
| ||
| @ Derron mmm, had to really dig into the code to find it. looks like flip -1 all animations are custom locked to millisecs(). I think the fps tick timing is either 45 or 60fps based on TTimer About the joystick. Will it cause a delay if there is no joystick present? |
| ||
| Will it cause a delay if there is no joystick present? Don't poll joystick count in your render loop. Really. It can be very expensive - depending on PC configuration. |
| ||
| I only poll joystick count outside of the render loop and have tried to minimise joystick polls to once per loop |
| ||
| tried to minimise joystick polls to once per loop You mean like 60 times a second? |
| ||
| Since it can be a such a PITA, you could always consider polling it say, once per second, in a background thread... |
| ||
| Or in a If (tick mod 60)=0 then PollJoystick tick = increased on each loop cycle @Millisecs Hopefully you took care of the millisecs wrapover after an uptime of 28days (there are threads about it here on the forums) Nonetheless it should work.. in most cases. Bye Ron |
| ||
| About the joystick. Will it cause a delay if there is no joystick present? At a bare minimum, You may want to just check for the presence of a joystick at the start of each level or something, and if there isn't don't poll it at all. |
| ||
| Just to be clear. I am not using JOYCOUNT() anywhere near the game loop, just things like JOYDOWN(), JOYHAT(), etc Question. What would be the best flip setting 0 or -1 |
| ||
I use this piece of code in my graphicsmanager-typeMethod Flip(restrictFPS:Int=False) 'we call "."flip so we call the "original flip function" If Not restrictFPS If vsync Then .Flip 1 Else .Flip 0 Else If vsync Then .Flip 1 Else .Flip -1 EndIf End Method If you know, all potential players will handle "vsync-framerate" without problems, then use "flip 1", else one of the others (with potential to "tearing" then). As my "engine" allows for lower FPS (I use delta-timing and tweening) I only "vsync" on request of the player (available as a switch in the settings). Note on "flip -1": If sync is -1 and the current graphics object was created with the Graphics command, then flips will occur at the graphics object's refresh rate regardless of whether or not the graphics hardware supports such a refresh rate. (source: https://en.wikibooks.org/wiki/BlitzMax/Modules/Graphics/Graphics) bye Ron |
   |