Ok. You guys are right. Waiting for Retrace fixes flickering. But i dont understand why it flickers in the first place. i draw the image to the off buffer, then i swap the pointers, and then i draw to the other buffer (thats now the off buffer) so how can it display an incomplete image. shouldn't …

So. ive done a couple things. I wrote a VESA init method, so I can use the VESA modes now including proper page flipping. for the regular mode 13 (without page flipping) ive reimplemented the memcopy in assembly. I also made sure that the printing time of the milliseconds wont show up in the …

Thats ... not great lol But its also not terrible. I suspect the printing of the numbers slows it down a bit. And if i can implement proper page flipping with VESA it should easily be 30-40% faster than now. Of course drawing real sprites is slower. plus all the game logic. But i think i can get …

Hello, I've tried to follow the VESA specification as in this document: http://www.petesqbsite.com/sections/tutorials/tuts/vbe3.pdf Specifically i was trying to obtain the protected mode entry point. I've copied the BIOS Image from C0000h and started Scanning for the signature 'PMID' couldnt find it …

which is 1000 Hz (or 1000 fps). hence why dosbox is not representative of real hardware. there are two things to note here. I dont wait for vertical retrace or anything. And also i've set the dosbox cycles to 100% in dosbox.conf: cycles=max If you give me a binary, I can test it on my 386 with an …

Bytes are 8 bits, you're only shifting by 4? Lol that was indeed the error. void GraphicsEngine::DrawRectangleASM(int x, int y, int w, int h, int color) { int screenWidth = 320; asm("movl $320, %%eax;" "movl %1, %%ebx;" "mulw %%ebx;" "add %0, %%eax;" "add %5, %%eax;" "movb %4, %%dl;" "shl $8, %%edx …

Doom MBF thanks. Ill check that out. Bear in mind that DOSBox performance is completely unrepresentative of actual hardware. I know. I'm just comparing relatively, from one implementation to the other (both in DosBox) I'm still a long way out of actually testing it on real hardware. Untested, but …

Also you need to put that in every compile target. During linking where you are using it, it's worthless. Geez thanks. That makes perfect sense. Quite amazing what one can learn by posting to a forum :happy: Just using -O3 correctly brought the combined drawing and flipping time down to 4ms. Thats …

I use this makefile to compile: all: mode13 objects.o: objects.cpp objects.h i586-pc-msdosdjgpp-g++ -c objects.cpp engine.o: engine.cpp engine.h i586-pc-msdosdjgpp-g++ -c engine.cpp main.o: main.cpp i586-pc-msdosdjgpp-g++ -c main.cpp mode13: objects.o engine.o main.o i586-pc-msdosdjgpp-g++ main.o …

Qbix wrote: you might be running in debug mode as well. Do you mean DosBox Debug or DJGPP ? How can i verify that im in Debug, and how would i change that ?

Thanks for the Replies You should check out whether it still uses the BIOS drawing function. If it does, this won't be really fast. Because that means a BIOS call for each individual pixel. I'm not using any Bios calls to draw. i write directly to memory. your flip is terrible. your doing a byte by …

Hello, Its my first post and i don't quite know whether this is the right place to post this. Sorry if its not. I started programming a little game using DJGPP. Im compiling in linux using the djgpp-linux64-gcc720 package. Im running my code in DosBox 0.74 The Program uses simple Mode13h (I have …