User talk:RossyMiles
Jump to navigation
Jump to search
- Congratulations on the true windowing and on the custom resolutions. A few questions from the Russians, though:
- Really, why make such a fuss about the "USB" thing? Playing Oni from a USB device never was a problem, so how can it possibly get "easier"?
- Why tell people to replace binkw32.dll even though it's a vtuneapi.dll you're building? so that it doesn't interfere with the current Daodan DLL?
- Why not call your project part of the Daodan DLL initiative, help yourself to our database, and assimilate all the features of the FASM build?
- geyser 02:54, 23 May 2008 (CEST)
- Thanks, in answer to your questions:
- I called it OniUSB because the original plan was to compress the binary data and extract it when needed, thus making Oni suitable for a <256MB flash drive. I guess it may need a name change but I'm not good with names, OniUSB is the coolest name i can think of at the moment :).
- OniUSB can replace binkw32.dll or be added as vtuneapi.dll it should work equally as well with either however because OniUSB forces Oni to use binkplay.exe instead of binkw32.dll, I thought it would be more elegant to go get rid of the original binkw32.dll. Another reason I chose to use binkw32.dll is to avoid conflict with the Daodan DLL.
- I'd really like to, however I don't know anything about assembly, I would like to help with future versions if I can. I provide the source code for free on the site so you can use bits if you want.
- I was wondering if anyone knows the memory locations for screen resolutions from the Russian game engine (and the ones I've missed on the English engine), I would like to make OniUSB compatible with as many engines as possible.
- Also I plan to join the forums soon.
- rossy 11:06, 23 May 2008 (CEST)
- You can't squeeze the original GameDataFolder into less than 300 MB. However, if you're thinking of the Edition, it's possible to have a GDF almost as small as 256 MB, uncompressed. Somehow I'm comfortable enough with a 512 MB device hosting an uncompressed Edition and some extras, but of course compressing the data would make it possible to fit the Edition into 256 MB instead. The only problem is, if the GDF is never seen by the user, how easy will it be to manage plugins (level#_Whatever.dat)?
- If your project and the Daodan DLL are one and the same, then there is no conflict and you can hook/patch most of the stuff through vtuneapi.dll As for getting rid of binkw32.dll, perhaps an even more interesting feature would be to make Oni able to play back other movie formats than BINK...
- SFeLi used FASM to build the Daodan DLL at first, but he has worked on a C version as well, so in the current situation it's more like he has bits of source code for you to use rather than the other way round. Once we throw the working source at you (soon), you can add features as you see fit.
- The layout of the resolution tables in the "standard" EXE is something like this:
.text:004083AF mov [esp+114h+var_FC.wResY], dx .text:004083B4 mov ebp, 1200 .text:004083B9 mov esi, 1080 .text:004083BE mov [esp+114h+var_FC.wResY+30h], dx .text:004083C3 mov ebx, 16 .text:004083C8 xor eax, eax .text:004083CA mov edi, 1920 .text:004083CF mov edx, 32 .text:004083D4 mov [esp+114h+var_FC.wResY+20h], bp .text:004083D9 mov [esp+114h+var_FC.wResY+28h], si .text:004083DE mov [esp+114h+var_AA], bp .text:004083E3 mov [esp+114h+var_A2], si .text:004083E8 mov [esp+114h+var_FC.wResX], 640 .text:004083EF mov [esp+114h+var_FC.wBPP], bx .text:004083F4 mov [esp+114h+var_FC.wUnused], ax .text:004083F9 mov [esp+114h+var_FC.wResX+8], 800 .text:00408400 mov [esp+114h+var_FC.wResY+8], 600 .text:00408407 mov [esp+114h+var_FC.wBPP+8], bx .text:0040840C mov [esp+114h+var_FC.wUnused+8], ax .text:00408411 mov [esp+114h+var_FC.wResX+10h], 1024 .text:00408418 mov [esp+114h+var_FC.wResY+10h], 768 .text:0040841F mov [esp+114h+var_FC.wBPP+10h], bx .text:00408424 mov [esp+114h+var_FC.wUnused+10h], ax .text:00408429 mov [esp+114h+var_FC.wResX+18h], 1152 .text:00408430 mov [esp+114h+var_FC.wResY+18h], 864 .text:00408437 mov [esp+114h+var_FC.wBPP+18h], bx .text:0040843C mov [esp+114h+var_FC.wUnused+18h], ax .text:00408441 mov [esp+114h+var_FC.wResX+20h], 1600 .text:00408448 mov [esp+114h+var_FC.wBPP+20h], bx .text:0040844D mov [esp+114h+var_FC.wUnused+20h], ax .text:00408452 mov [esp+114h+var_FC.wResX+28h], di .text:00408457 mov [esp+114h+var_FC.wBPP+28h], bx .text:0040845C mov [esp+114h+var_FC.wUnused+28h], ax .text:00408461 mov [esp+114h+var_FC.wResX+30h], 640 .text:00408468 mov [esp+114h+var_FC.wBPP+30h], dx .text:0040846D mov [esp+114h+var_FC.wUnused+30h], ax .text:00408472 mov [esp+114h+var_FC.wResX+38h], 800 .text:00408479 mov [esp+114h+var_FC.wResY+38h], 600 .text:00408480 mov [esp+114h+var_FC.wBPP+38h], dx .text:00408485 mov [esp+114h+var_FC.wUnused+38h], ax .text:0040848A mov [esp+114h+var_FC.wResX+40h], 1024 .text:00408491 mov [esp+114h+var_FC.wResY+40h], 768 .text:00408498 mov [esp+114h+var_FC.wBPP+40h], dx .text:0040849D mov [esp+114h+var_FC.wUnused+40h], ax .text:004084A2 mov [esp+114h+var_B4], 1152 .text:004084A9 mov [esp+114h+var_B2], 864 .text:004084B0 mov [esp+114h+var_B0], dx .text:004084B5 mov [esp+114h+var_AE], ax .text:004084BA mov [esp+114h+var_AC], 1600 .text:004084C1 mov [esp+114h+var_A8], dx .text:004084C6 mov [esp+114h+var_A6], ax .text:004084CB mov [esp+114h+var_A4], di .text:004084D0 mov [esp+114h+var_A0], dx .text:004084D5 mov [esp+114h+var_9E], ax .text:004084DA mov [esp+114h+var_104], eax .text:004084DE mov [esp+114h+var_100], eax .text:004084E2 mov ebp, ecx .text:004084E4 lea esi, [esp+114h+var_FC]
- This is enough info to replace a resolution or two with a hard patch, but perhaps not for what you have in mind (expect more info from SFeLi). As for the Russian engine, the current intention is to stop supporting it while adding support for non-ASCII characters to the standard engine.
- I personally have been completely absent from Oni Central Forum lately, and neither SFeLi or Neo ever registered there. If you don't mean to provide intensive troubleshooting and support via the forum, then there's no hurry to join ^_^
- geyser 16:11, 23 May 2008 (CEST)
- Hi, I got the source code for the Daodan DLL from SFeLi. I have discontinued the OniUSB project and I'd like to help you with Daodan if I can. I've been rewriting the code in pure C and merging the OniUSB and Daodan source code. It's going well and I have made a C source file and header which might be the start of an Oni SDK. The source code and test DLL can be downloaded from http://oniusb.googlepages.com/Daodan.7z (dead link) (early beta). Also, I was wondering if there was a designated place for Daodan DLL related discussion on the wiki.
- rossy 13:20, 25 May 2008 (CEST)
---
AutoIt3
FileOpen("filename", 16)
Ohh... somehow the German help lacks the flag information - or I didn't notice it...
So... can I also tell AutoIt3 to read binary data from a specific postion and overwrite it? (F.e. jump to position 0x0040 and read/overwrite the first 4 bytes.)
Ssg 14:44, 23 June 2008 (CEST)
The question for me is why I would need to open it. I was just planning on bouncing commands to Onisplit.
@Ssg I'm not sure if AutoIt can do that, maybe it is not as powerful as I thought. If you want to do something like that, C or C++ is a good option.
@Gumby Bouncing commands is easy in AutoIt. You can use Run and RunWait to run the exe. DllCall can start a dll so it might be more efficient to compile OniSplit as a dll and call it with AutoIt.
rossy 03:42, 24 June 2008 (CEST)
Ok...thats what I thought. I'll probably just leave onisplit as it is, and have there be a place to specify Onisplit's path...