User talk:RossyMiles

Congratulations on the true windowing and on the custom resolutions. A few questions from the Russians, though:

1. 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"?
2. 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?
3. 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:

1. 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 :).
2. 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.
3. 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)

1. 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)?
2. 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...
3. 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.

Gumby

@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...