pouët.net

wow, and I thought it's a wine problem!

good job guys! \o/

Massive hardon!

benryve and LiraNuna: Yes. its related to some stride stuff probably. I'll try fixing that for BP as well as upgrading the texture size. Just need to find some time...

New version of Heaven7 HD. More video modes and experimental fix for the overly tearing in 1400*x and 1680*x modes. Feedback appreciated.

The problem, as i understood, was that the width of the renderer must be divisible by 32.
Yes, I think it's some kind of width!=pitch problem, that affects the code that adds alphablended 2D pictures.

rare, it seems to work!
but, did you just crop the resolution to the nearest lower value that is divisible by 32?
i did that too, and the thing is, the internal rendering framebuffer (whose dimensions are what you give, in this example 1664 i presume) gets upscaled (either by directdraw or by some routine) to the actual fullscreenmode resolution (1680 in the example), just before the final blit...

The result is that because of this slight stretching, you don't have the "native resolution" feel anymore.

but interesting anyway :)

Hmmm. Couldn't try it here. I'll look into it tonight.

New version.
- Calculate correct drawing area shift before calling IDirectDrawSurface::Blt to prevent automagic stretching.
- Experimental vsync option that tries setting DDBLT_WAITVSYNC.

Feedback always appreciated.

excellent! it crawls on my native 16:10 screen resolution :D

rarefluid: please don't forget to compress your final version under 64k :)

Works like a charm!

This time it works, in windowed and fullscreen! I guess you zeroed the five last bits of the width? And you found the code responsible for the final blit...

However, it seems tat there is still VSYNC tearing, even when the checkbox is checked... don't know.

WaitForVerticalBlank() was not working for me, so I tried the DDBLT_WAITVSYNC flag. This might need some more work. Maybe I have time this weekend...

Hi every one!
Thats a nice play hacking this intro :)
I hear that Picard dont release the source because its a messy. (lots of hand written ASM/MMX and "fastPressure" code)
I dont want contribute to crash you playground, but I give here (maybe) two ways of contact Picard.

His name is "Kovács Gábor" and I have talked with him about heaven7 and raytracing in Jul 2004 with the following email: picard _at_ topcat _dot_ hu
and seams that this mail is forward from picard _at_ demoscene _at_ hu

also I found online this post by Picard: 09-09-04
"i'am currently on irc.corecodec.com:6667 username: picardbeta channel: #betaplayer"

but please, don't bother the gods :)

Humans play with genetics and never asked god the sourcecodes :P isn't fun! :P Hacky is fun!

btw... next year will be the 10 anniversary of heaven7 :O We should start a special anniversary version release :)

actually we have the source. :) the code is not as messy as expected, but it is 100% ASM and only compiles on TASM 5.3, which is sad, because it doesn't support SSE opcodes which would give lots of possibilites for speed optimization. Converting from TASM to NASM/MASM Syntax sucks btw...

I have asked stephen if we could collaborate and open up the source (set up a web-svn) so other scene hackers could have a stab at it, but he didn't definitively say that it's ok, and I'll respect that till I hear otherwise.

I'm working at it when I have time and plan to do a version with (at least) fixed vsync and better texture resolution till BP09 so we can show it in 1080p or something... Would be neat to have some speed optimizations and/or parallel processing in the new version, but no promises 'bout that! (Joghurt! Help! ;P )

You can always enter the opcodes as raw data into the code. I remember doing that when I had a really old version of TASM that couldn't do RDTSC. But of course, that's not exactly fun..

nope. ;) I remember using the prefix "db 66h" from my Turbo Pascal times, too...

Could it be possible to convert all the source, data binarys, music, blablabla to a more friendly C code ? ... monkey Coders?!

With monkey coders, yes. ;)
But even only converting it to NASM-compatible assembler code would be nice...

picard we did not contact, but stephen did, and gave me and rare the right to use the sacred artifacts for noble goals :)

i'm not really into SIMD, howevwer, i see no problem in adding NASM (or whatever) code in the project, just add another file, tell visual studio to compile it to nasm, and link the object file. There may be some function call decorating convention to respect. that way you could add SSE functions that you call from original code...

should work!

yeah. should probably work. converting the whole source though is a lot of work...

just fucking send it to india and have it converted for 5 dollars. or leave heaven7 for what it is. what's this weird obsession with recoding a (dated) 64kb intro?

make a new raytracer 64k in highres. that would actually be interesting.

(sorry for shitting all over everyone's time consuming attempts at making this work :-))

yeah. thanks. you're welcome.

winterniels:
wow, you dont seem to be ironic. I'm sorry then.
How sad. whatever you do on the internet some people will not like it and make some rude comment.

As has already been said i made it cause i enjoyed it, as a tribute. I love thins intro. it's pretty simple really. Then if people want to try and enhance new things, why not.

Maybe though, i can see your point. Thing is, i cant code a 64 raytracer, for now at least.

Thanks to all the people that gave good feedback.

winterniels: thats just rude

I have to say I kind of agree with Niels here. You got it running at semi-decent resolutions, so let's just call it a day :)

It's much more interesting to do something new. And if you insist in rehashing an old intro, do a remake! You'll be like an r&b producer!