twkr

Members
  • Content count

    77
  • Joined

  • Last visited

Community Reputation

162 Neutral

About twkr

  • Rank
    Member
  1. DirectDraw7 Flip very slow

    dont use flip unless you really need it. just blit the back buffer to the primary surface instead. it should improve the speed quite a bit.
  2. you could also disable the screen saver when then game starts and re-enable it when the game ends. void ScreenSaver_SetEnabled(bool value) { ::SystemParametersInfo(SPI_SETSCREENSAVEACTIVE, value, 0, 0); ::SystemParametersInfo(SPI_SETLOWPOWERACTIVE, value, 0, 0); ::SystemParametersInfo(SPI_SETPOWEROFFACTIVE, value, 0, 0); return; }
  3. the file header begins at 0x100. the stuff before that is used for processor interupts. http://www16.brinkster.com/twkr/documents.asp from pan docs: >> 4. The SNES and Genesis has an some cartridge information in the ROM. Does the Game Boy have some info, too? ------------------------------------------------------------------ Sure, why not?! The Internal Info block begins at $100 and it's format is as follows: $100-$101 - 00 C3 (2 bytes) $102-$102 - Lo Hi (Start Address for Game, usually $150 it would be written as 50 01) $100-$133 - Nintendo Character Area, if this does not exist the game will not run! 000100: 00 C3 50 01 CE ED 66 66 CC 0D 00 0B 03 73 00 83 000110: 00 0C 00 0D 00 08 11 1F 88 89 00 0E DC CC 6E E6 000120: DD DD D9 99 BB BB 67 63 6E 0E EC CC DD DC 99 9F 000130: BB B9 33 3E $134-$143 - Title Registration Area (title of the game in ASCII) $144-$146 - NOT USED $147 - CARTRIDGE TYPE 0 - ROM ONLY 1 - ROM+MBC1 2 - ROM+MBC1+RAM 3 - ROM+MBC1+RAM+BATTERY 5 - ROM+MBC2 6 - ROM+MBC2+BATTERY $148 - ROM SIZE 0 - 256kbit 1 - 512kbit 2 - 1M-Bit 3 - 2M-Bit 4 - 4M-Bit $149 - RAM SIZE 0 - NONE 1 - 16kbit 2 - 64kbit 3 - 256kbit $14A-$14B - Maker Code - 2 bytes $14C - Version Number $14D - Complement Check $14E-$14F - Checksum HI-LO (2 bytes in Big Endian format, high byte first) <<
  4. ken

    i think you are in the wrong forums. these forums are for game development not game playing. maybe try the gamefaqs.com forums instead. http://www.gamefaqs.com/search/index.html?game=street+fighter&x=0&y=0
  5. if the DLL crashes before you even get to main() then you should try loading it in code inside the main function. then maybe you can debug the DLL. bool Load(const string &sFilePath) { Unload(); bReadOnly = false; return (hModule=::LoadLibraryExW(Marshal::ToWin32(sFilePath), 0, 0))!=0; } virtual void Unload() { if (bReadOnly) return; if (hModule) { ::FreeLibrary(hModule); hModule = 0; } return; } template<typename DATATYPE> DATATYPE FindFunction(const string8 &sName) { return (DATATYPE)::GetProcAddress(hModule, Marshal::ToWin32(sName)); }
  6. i usually use critical sections: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/critical_section_objects.asp
  7. directx bitmap manager

    >>When do you load those bitmaps, when you load the map of the current area? yes >>If so, how many offscreen_plain surfaces do you use? Let's say one map contained 3 NPCs whereas another contained 12. Would you create 12 surfaces for sprite sheets and just load 3 on the smaller map? you would use a dynamic array or linked list of surfaces. so if you only need 3 for the map then you only create and load 3 surfaces. then when you load another map you can clear the array and create and load how ever many surfaces you need for that map.
  8. directx bitmap manager

    you do not load any files in the render function. files should be loaded once, in the load function. so you would have many offscreen surfaces with the bitmaps already loaded onto them. and you just use the offscreen surfaces in the render function. offscreen surfaces: http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/ddraw7/directdraw7/ddover_53jr.asp
  9. directx bitmap manager

    Should the 256x256 bmp contain all the sprites for that area? no. Should that bmp contain my tileset for that map? one (or more if they all wont fit on one) of the offscreen surfaces should contain the map tileset. if the background is static (like in a 2D fighting game) you might want a background offscreen surface which would be the same size as the background bitmap. How could I manage variably-sized sprites? For instance, one frame might be 100x80 where the next could be 90x90 for a different pose of the same object. its all about the from and to rectangles when doing your blitting. the from rect may be (32,32,32+90,32+90) and the to could be (70,300). so the actual size of the surface is not an issue when it comes to sprite sizes (as long as the surface is big enough to fit the sprite). What should go onto that 256x256 bmp? Just one character, all characters in that map? just one character, unless you can fit all of the characters. Sorry if I don't get what you're saying, but I understand the various buffers and color keys. I'm just having trouble encapsulating all that into a class. the class should be an offscreen surface class not a bitmap class. the only time you use bitmaps is when you load them from a file and put them onto the offscreen surfaces. in the render function (where you draw one frame) you would first clear the backbuffer or blit the background surface if you have one. after that you would blit the various offscreen surfaces. like if you have a character on a surface at (32,32) and the sprite is 90x90 than you would blit that area (32,32,32+90,32+90) from the surface onto the backbuffer at where ever the character is located on the screen.
  10. directx bitmap manager

    put your bitmaps onto 256x256 sized off-screen surfaces (usually during a load screen). use transparentcy (like a violet background #FFFF00FF). the backbuffer should always be the same size as the primary buffer (the screen size, maybe 640x480). blit the offscreen surfaces to the backbuffer as needed but not the whole surface, just the area with the sprite you want.
  11. i had the same problem a long time ago. my triangle was really small and i think i just changed the depth/field of view (whatever its called) to fix it. i was using Direct3D though, not OpenGL.
  12. you should probably use a binary file format unless you want users to be able to easily edit the data themselves. if you dont know how to do binary file access then now would be a good time to learn. if you are programming for a Windows OS then check out: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/file_management_functions.asp i would suggest writing a File class that encapulates some of those functions including: CreateFileW ReadFile WriteFile GetFileSizeEx SetFilePointerEx SetEndOfFile CloseHandle
  13. timer in c++

    ::Sleep(1000); LARGE_INTEGER freq; if (::QueryPerformanceFrequency(&freq)!=0) { dFrequency = (double)freq.QuadPart; } LARGE_INTEGER counts; ::QueryPerformanceCounter(&counts); return counts.QuadPart;
  14. make sure you test the speed in Release mode. the code would obviously be slower in Debug since it does not optimize at all.