Harha

Removing I_Sleep(1); does make a difference in gameplay/fps-wise, but nothing in the dot section. Dot section always seems to report full framerate, though it seems to behave slightly differently (the first dot is blinking) but still, just one dot. Yeah, obviously I am aware of this and I think you could see it from my previous posts. The program running at full 35 frames per second constantly doesn't always mean the visual feedback what you see on your window is the same. For some reason VMWare causes this, it runs completely fine at 100% speed in the background but displays the outputted framebuffer poorly. https://dl.dropboxusercontent.com/u/5184285/chocolate-doom.webmhd.webm There's a video showing how the framerate differs between debian vm and windows 7. It isn't a lot anymore, since removing I_Sleep did help a bit, but it's still noticeable. https://dl.dropboxusercontent.com/u/5184285/out%20%282%29.ogv There's a video showing that the virtual machine can actually output smooth gameplay just fine. Using prboom-plus this time with default settings. Anyways, as interesting as this might be I'm sick of trying to fix it. I tried to play around with the rendering loop stuff with no luck. I think it's SDL being incompatible with the vmware stuff somehow. Edit: Weirdly though PrBoom seems laggy in the video. :D That's just because the recording software I'm using on linux isn't recording it at the full fps at all, Fraps which I used for the chocolate-doom video is recording at 60fps though. Anyways, chocolate-doom on windows feels as smooth as PrBoom or PrBoom-plus on linux virtual machine, which is what bothers me.

I was using PrBoom, not the plus version, with default settings, resolution just set a bit higher than the normal. I commented out that line, did make uninstall and make clean and then make and make install, tried the game out again and it seems like it reduced the lag a bit. It's still noticeable when I'm comparing it to the performance my host os delivers but it's better. I haven't looked into the doom source code that well but to me it looks like the loop is intended to fix some timing problems, so that it triggers whenever something is incorrect and then sleeps 1ms each time and does that until the problem is fixed. I didn't honestly have too much interest in looking at that so I cannot say that it's being triggered each frame multiple times in my vmware setup or something like that but I guess that's what you're wondering? I also tried out the -devparm (before I recompiled with the small source edit) and got these dots.

I can't access my pc atm but when I can I'll try to fiddle around with the main loop and rendering loop and see if I can make it work, if that -devparm doesn't do anything. I wouldn't count on SDL_Delay(Uint32 ms);

timed 2347 gametics in 199 realtics (412.788940 fps):D What the hell. I don't understand this anymore...

Virtualbox is pretty bad anyways. I think you'll have much better experience with for example QEMU. Anyways, I compiled and tried out prboom, it runs silky smooth, really really smooth. So I guess it's just a matter of the VMWare not liking the way chocolate-doom renders things, for some reason. Both, the software rendered and GPU rendered versions of prboom worked pretty much identically.

I never said my hardware would be at fault, I said that VMWare's own virtualization tech doesn't apparently support 2D software rendered graphics that well. And yeah, I will surely try out the live-cd before installing the OS. :P I'm not using Virtualbox, I'm using VMWare, which according to my research/tests performs a lot better at everything. The virtual machine is silky smooth, while in Virtualbox there are random jitters and things like that which are rather irritating, present in any distro, even in a minimalistic Arch linux / LXDE setup I tried. I'll try some OpenGL port I guess, it will most likely run fine. I'll do just that, thanks. I'll probably give this a try too. I'll report back here when I'm done. ;P

So, I set-up a debian 8 x64 OS in VMWare with a MATE desktop environment. Everything works fine, I cloned the latest chocolate-doom source from the github repo, compiled it with the latest gcc and installed it. It works fine, but there's one slight problem. Framerate is crap... I have an Intel Core i7-4790K 4.0ghz processor and a 'slightly' older Ati HD48900 GPU. The virtual machine runs absolutely fine and I gave it 4 cpu threads and 4gb memory, I have all the VMWare drivers installed and so on, so 3D graphics or anything like that shouldn't be an issue. So I really can't understand why would a simple game like doom lagg... The framerate is around 10-25, changing constantly. Audio works fine. I can guess that chocolate-doom is purely software-rendered, but still, it should run absolutely fine... :/ Anyone knows what could be causing this? I'm quite sure it's VMWare's fault, I'm planning to install debian on my main computer after doing some more testing using this virtual machine so I'd like to know whether this is debian/MATE's fault or a fault in the virtualization tech. Here's a video demonstrating the framerate; https://dl.dropboxusercontent.com/u/5184285/out-1.ogv I've been trying to ask around in VMWare's and Debian's irc channels but nobody knew what caused it. Chocolate-doom seems way more slick/responsive in my host OS which is windows 7 x64...