pouët.net

posting in a legendary thread.
oh wait this ain't /b/.

Anyhow, great job HeLLoWorld! always wanted to see that demo in awesome-res. Keep up the good job, I'd mirror if I could get a hand before the rest.

thnx HeLLoWorld! what'll be the next feature? FSAA? (=

btw, higher textures resolution will be nice too (=

Just so you know, i have better understood ho to get a resolution that works, aswell as how to get fullscreen (16/10 fullscreen is possible by modifying some other bytes in the lea/shr sequence....epic win!).

And, some Parisian dude that just happens to both have a 24 inches display, and be a friend of mine, successfully tested a 1856*1020 windowed version (Salut Nico!). Pretty cool if you ask me.

1680*1050 fullscreen is possible but it will have artifacts, nothing i can do atm :(
1920*1200 fullscreen and 1440*900 fullscreen are "likely" to work flawlessly!
thats two fucking megapixels :)

Well I'm aware maybe someone will come with the source and make a version that enumerates modes and ridicule this a bit... but so long i've enjoyed it.

Also, in case some Exceed member is around : i realize that, i didnt ask nor get permission or anything, i apologize for that. I'm not ignoring the authors or anything, it's just that i don't know you :) , i didnt think i could get the source, and it was just a test at first. And again, i don't want to seem to be trying to take the slightest undue credit: i re-state i'm just overwriting some bytes, it's meant to be seen as a tribute to your work, allowing it to look even better today.

yeps, tweak the texture resolutions too cos now it still is lo-fi...

L1NK, christmaali, the texture resolutions, i'm not *quite* sure i can do that... :)

I can confirm that the 1680 res works fine on a 24" widescreen. Unfortunately, one of the cooler effects (pseudo depth of field via blurring) is now almost imperceptible because of the high res. Still, very cool!

...and thanks for doing this, as we can now consider H7 as an easter egg on MC3 :-)

i'm quite sure that texture resoltions in exe is smth'n like 64*64, 128*128, ..., 2^a*2^a. or it can be smth'n like (2^a-1)*(2^a-1). (= so maybe it's not so impossible to find and change them as it seems to be.

L1NK: There's a high chance that the texture generator is quite resolution-dependent.

maybe... but it's seems to me not while looking 1280 version... anyway we can force it to multiply real rez on 2 for example so intro will think that it's executed in 2048*1536 mode or smth'n like that.. we need only to find where it takes current rez..

Is anyone else getting a lot of flickering of the shadows in the "green ground with light beams" scene at about 1m8s in?

If the textures are being generated, i don't think it's easy to tell the program to allocate and create larger ones... and then the patterns must scale correctly...and then when the tracer reads them it has to do it correctly also, i mean texcoords etc.

If the textures are on-the-fly procedural, it's atleast as tricky, its means finding and modifying the "shader".

Unless of course, all this has a global unique initial "size" parameter that tweaks everything... in which case i must still find where it hides :)

(I'm not sure i understant what you mean L1NK)

trixter:
1664 only works windowed.
And yes, you're right about the blur filter, i guess it's a 2*2 or 3*3 averaging, so it's almost imperceptible now... we would need customisable gaussian blur :)
An easter egg on MC3?
And yes you're right, i too get a lot of shadow flickering on the green ground with light beams scene, didnt notice that... It seems to be present in the original, although almost imperceptible. The greater the resolution, the more flickering. So maybe it's related to the FPS in fact, but i can't know for sure :)
while i'm at it, theres some strangeness in the shadows of the columns in the temple scene, and at very hi res, the disc that makes the ground of the temple seems to be beginning to lose some pixels :). strange.

The last two bigger resolutions do not work in windowed mode for me. The demo and music starts but there is no window. Am I doing something wrong?

optimus: wow tha's bad... :(

it looks like your desktop would not be large enough...
Your desktop must be at least (maybe even more) 1440 for the 3rd res and 1664 for the 4th, is this okay?

other that, i don't know...

The aspect ratio (x/y) for the visible area is 1.818... or 1,828... in some cases; width and height are always divisible by 8!

I'm currently examining the executable with IDA. How would I actually INSERT code/data into the executable, not just change existing code/data? I'd need to somehow adjust all jumps/pointers to the area after the point insertion... Is there a way to do this using IDA?

what we usually do is just append code in an empty area, jump there and jump back.

The problem is that I want to expand the mode list. The is no space in the data segment for that...

Hello again.
As i said i'm not very experienced in reversing, it's cool there are others willing to "work" on this :)

I used ollyDbg.

I think you should use the last version i posted (in the ZIP, with the unpacked original), cause previously i didnt unpack it with upx but instead with some other tool that didnt unpack it as cleanly as upx.

Also, there is info in the readme in the ZIP.

As far as I understand the actual modeSet, FOR FULLSCREEN, is located at adress 04013E2 (ollydbg says that) : opcode FF57 54 , thats CALL DWORD PTR DS:[EDI+54] .

eax is Y, edx is X.

some bytes before that theres the code that computes the Y fullscreen res based on the X specified in the data list.(Y from data list isnt used for modeSet but specifies how many letterboxed pixels are drawn).

this code is: Y=X*3/4.
LEA EAX,DWORD PTR DS:[EDX+EDX*2]
SHR EAX,2

Heh. thats not very customieable :)
BUT in an epix hack i realized i could do 16/10 (5/4) with this code without reassembling :

LEA EAX,DWORD PTR DS:[EDX+EDX*4]
SHR EAX,3

Hehe. works.

that way more fullscreen modes are available but with another executable.

The algo for choosing X and Y that dont cause problems is :

For windowed mode:
-----------------------------
choose X, what you want.
Make it multiple of 32 (i think) otherwise there are the artifactd of the slopes on screen.
Additionnally, it doesnt work if it's exactly your desktop resolution, it must be less (otherwise it doesnt start). too bad.

calculate Y :
Y=X*0.55. It can be less but if it's more you will either have garbage at the bottom, or crash after first scene, or doesnt start at all.
Then reduce it to the next multiple of 8, otherwise there are a few lines of garbage at the bottom.

Thats it.
Put these two numbers in the 4-element list at offset 0x10027 in the file and it should work(note that just after the list is another list with ascii strings if you want to modify).

For fullscreen:
-------------------
the same as for windowed, except you are allowed to make X equal to your max screen resolution.
The program calculates X*3/4 blindly(lea/shr) and tries to set the mode.
(that way i got 1024*768 and 1280*960)
if this fails you get 640*480*16bpp.
By making the ratio 16/10 (lea/shr) new modes can be triggered (1440*900, 1680*1050, 1920*1200 (probably! not tested))
Note that 1680 works but fails the requirement of being a multiple of 32 so there are artifacts...Very sad :(.

Thats it!

(and if you put some X and Y in the file but breakpoint before the setFullscreenmode and force another (bigger) valid mode, it will set the new mode, run the demo with the smaller values in the file, and stretch the output to scale it to the mode bigger mode).

Raredolf:

I did only simple patching, not adding bytes.

I guess the best way to do what you want would be to tell the debugger to rebuild the file after having replaced an instruction with more instructions, but i dont know if it can do that.

Maybe the debugger can output an assembly source ready to be assembled in which case it allows what you want...

i didnt really investigate the code so i dont know how (if possible) to add video modes.

i mailed to rob@excedd.hu and warp@exceed.hu as mentioned on http://www.exceed.hu/ ... and i got a delivery status notification (failure) ... thats sad, I don't know how contacting exceed would be possible.

Here's a file that tries 1920 fullscreen !!!!11!!OMG

If someone with a big screen could test... :)

I'm quite sure it works because my windows+nvidia seem to be able to set the mode... (bigger than onscreen pixels)... I just see 1680*1050 but the framebuffer clearly is 1920*1200 and i can "scroll" by moving the mouse... wtf :)

Make this one high rez!!! I will try it actually, but I have no experience reversing. I think it would be fun to try.

http://pouet.net/prod.php?which=8758

that's not that simple - heaven7 is easier cos it already supports various video modes so the rendering is proportional, bakkslide7 was probably hardwired to run in only a single resolution.

b0ib0t: what Gargaj said :) ... but its already a port so source must be available maybe? but even then if things are hardwired everywhere its not simple... is the Dos version the same resolution? windows version looks like 640*480, if Dos is lower it means it could be possible...eh, more work ! :)