pouët.net

HelloWorld: The aspect ratio seems to be hardwired to 1.81 It loads this number from some location. You need to change this for the modes having an aspect of 1.6 (1280x800, etc.) otherwise the output will look wrong...

I'd rather like to understand the code, add more resolutions and improve texture resolution than trying to hack in new modes all the time...

Raredolf:

yes you're right of course, there are more possibilities by actually reversing the code...
however i explained the limitations i found, and the difference betweeen windowed and fullscreen (it is a bit complicated i find)

If you found something hardwired to 1.81 (which is the inverse of my 0.55), that must be the ratio of "something in the engine", I don't know what. But, the engine looks correct without changing that, even for example in 16/10 fulscreen : the spheres are round :) . You just view more or less of the scene when you change the ratio.

I think what prevents the demo to be running in ANY ratio (maybe that's what you meant)(in which case we could just pass the initial X and Y to the setfullscreenmode and NOP the y=x*3/4 part) is the "overlay" tranparency effects that maybe assume "letterboxed" format when they blit, or something... see the second screenshot on this thread's first page.

But even then, i think the "slopes" artifacts would remain for non-multiple-of-32 widths.

HeLLoWorld : adding more intructions is generally done through code injection and code caves as explained in many gamehacking tutorials. now in an optimized asm-written intro there are prolly few exploitable code caves :>

then maybe a method is to tamper with the PE header and extend the code section... dunno exactly, i've never had to do such a dirty thing though :P

hello guys, xmas and everything :)

to run h7 in hd texture size is theoretically possible, but not it's an easy task.
the texture generator could be tweaked to produce even 4096x4096 textures. in this case the txt size will be 64M, the generator itself requires 320M, and - if i recall correctly - there are 21 active textures in the h7 - so it'll be around 1.5G memory - just for the textures :)
but even if we're not so greedy and we are happy with 1024x1024 textures, the raytracer engine is hardwired to 256x256 with the usual bl=x, bh=y, mov eax,[esi][4*ebx]. so it seems to be difficult to modify that.
anyway, this method is not just the most simple and short, but also the fastest :)

Hmm. Sounds like a challenge ;)
I'll try to get something working over christmas... I haven't looked around for emtpy parts of code. It is quite possible that there are some.
It is probably not that hard to extend the data section though, to make H7 support/show the extra video modes. And tweaking the aspect ratio should also work.

stephen:
interesting :) . However even then for example with 1024*1024 (2^10) textures instead of 256*256, we could access texels by doing ebx=y, shl ebx,10 , add ebx,x instead...but ofcourse there may be many places with this, or other limitations due to 8bit nature of texcoords...
the generator requires 320M to begin with ? in 2000? maybe i misunderstand, windows task manager reports something like 20Mb usage...

Raredolf:
Ok! Good luck with that. I wonder what the 1.81 hardcoded value does, and if the crashes due to aspect ratio not being 0.55 are due to the code copying the overlay pictures to the screen...

helloworld, I believe that stephen means that for 4096^2 textures, the generator would need 320m...

texel's right. anyway, my english is far from perfect, sorry for that :)

my points were:

-the generator itself needs five times one texture size to operate
-there are 21 textures used in h7
-so it's because the textures are not procedural when we want bigger textures, the memory footprint increases quickly

-the raytracing engine is fully hardcoded with 8bit x 8bit texture access
-even if we tweaks the engine the performance drops significantly

i hope what i meant it's clear now :)

I managed to find some space in the data section to squeze in resolutions up to 1920x1200. I still have to test whether the aspect ratio matters (x/y 1.6 vs. 1.81), so I might have to find some space in the code section to add aspect ration switching depending on the resolution chosen. I think adding an 16:10 checkbox might prove hard, though that would be the optimum solution.
I think if there's enough space left I can even edit the texture generator and the texture access. I will for sure be slower, but fuck that, we can make some HD videos with proper texture resolution of this baby! :)
I'm currently not at home, but when I get back I'll upload what I have till now...

Would it be easier to jitter the texture coordinates and avarage a bunch of frames (doesn't have to be done on the fly) than increasing the texture size?

would it be easier to ask the coder to release a new version?

Raredolf:
That sounds great! Did you manage to get something that works in windowed and fullscreen with all these different resolutions?
I kind of left my "work" where it was, good luck with your tweaking! You seem to have some good skills :) , i guess you debugged the initialisation procedure(i didnt)?

user 256:
Yes you're right, but I don't know the coder and wasnt able to contact Exceed...
Stephen here replied just one day ago (thank you stephen) and I don't know if the sources are available/ if the coder (picard) is still around.

i don't see any problem with contacting exceed ;)
a couple of exceed members are here on pouet like d-lee, murphyEXD, teo_exd, picard. so it's not impossible to reach us even some of us are unapproachable like movie stars :)

as you may know - or maybe not - picard running his business in full time. he has corporate obligations with that, so i think it's very unlikely to him to sit down and dig into his old assembly code to rewrite it.

furthermore, picard stated back in 2002 (http://www.pouet.net/demoblog.php?who=12) that he's not going to release the sourcecode, because he thinks it's crap. i saw that code with my eyes and i think it's well structured and clean, but maybe he has just high standards :)

so what i see is that we have two options:
-hack the code
-beg for the source

either one way or the other is a challenge :)


to hack the code maybe i could provide some very-very little help :)

for start i have an idea:

you guys try to isolate the texture generator routine. it's fat, it's around two and a half kilobytes in size unpacked. when found, you have to write a little piece of code that saves the generated textures to the hard drive. if you found holes in the code it must be possible to do that. after that you just have to patch the generator code not to generate textures anymore, but to load them from disk. and voila: you have two and a half kilobytes of space to put hacked code into it in the code segment :)

a hint: in the test versions of h7 there was a bit of code that did the load / save thing. i really doubt that it's still in the final code, but who knows? maybe it's just worth a shot to look out for that :)

if you can manage to load the textures from disk then we have another possible opportunity. those scripts become unneccessary, and we could use their space to anything. if we're lucky, and the texture's little generator scripts are stored in the code segment by some miracle, then we have another one and a half kilobytes that we can use freely - but i'm a little bit pessimistic on this one, however :)

stephen : it's just that 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). maybe i did something wrong.
thanks for the interesting infos :)

wouldnt this be alot easier if you just wrote your own vesa driver (i assume h7 is in software).

Perhaps Opensource should be bigger in the "scene". I ALWAYS appreciate it when a prod comes with source. No matter if its crappy code.

then why didn't How To Make Coffee come with source?

would you like it to?

Actually I thought about it, but I dont know how to make the source link for the prod hehe. Tell me how and I will add it! ;)

pantaloon : i cant decide if you're ironic or not :)
i seem to recall the dos version could be told the resolution you wanted by means of command line arguments, could be a way, but for this the dos version must first run OK under windows...

b0ib0t : yeah... i'm usually critical of opensource fanboyism, but i must (reluctantly :) ) say, for example here it would allow the demo to survive/transcend OSes and environments, look at how "tube" runs under some obscure menuetOS for example. whatever :)

helloworld:

it's strange :)
as far as i know we all use our exceed.hu mail address till today, so it's a little bit weird to hear that you have a delivery status issue, but ofcourse it's possible.

no hard feelings anyway, warpig almost never answers to e-mails, even for me :)

but fortunatelly, it seems that the communication problems are getting 'deprecated' now :)

i contacted picard to check this thread.
maybe we can get some help ;)

\o/ I'll give him a free beer if he does a proper HD version :)
But I think I can maybe get there given some time... IDA Pro ftw. ;)

i wanna thumb this thread up!

thanks! :)
Did nobody test the 1920*1200 version on page 3 ?