|
TANTRO by Hornet [web]
[nfo]
|
||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|||||||||||||
|
popularity : 60% |
|||||||||||||
alltime top: #9116 |
|
|||||||||||||
added on the 2009-04-22 01:13:46 by Gargaj  |
||||||||||||||
popularity helper
comments
This is a Tandy 1000/PCjr intro.. works in DOSBox with cycles set to 800 (yes, 800) and machine set to tandy.
added on the 2009-04-22 02:04:02 by phoenix 
No music, and only one grayscale effect.
BITS: You're just deaf and colorblind.
Well, i really like the music, but for a real tandy 1000 you must set the cycles to 300 or so, since you only have 4,77Mhz. As i said, the music is nice for Tandy but the graphics routine is not really optimized, rather slow and skips lines...
Well, i really like the music, but for a real tandy 1000 you must set the cycles to 300 or so, since you only have 4,77Mhz. As i said, the music is nice for Tandy but the graphics routine is not really optimized, rather slow and skips lines...
"I might be the first person ever writing object-oriented code on a Tandy." /Trixter/
Wowa! Releases on such retro PCs makes me happy!!! The sound and gfx are funny and the rotozoomer is fast enough (well not a full framer but for the size and cpu I think it's fine).
it runs full framerate on the actual tandy, we'll probably get video before too long..
I like how 'greyscale effects' have color these days.
nice release. only music is stopped too suddenly
phoenix: yes, i mixed something up. Its really around 1200 cycles. 4770 clock cycles/4 =CPU-cycles in Dosbox. My bad.
Coooooool. :) DOS forever. ;)
What gargaj said :)
For everyone getting GRAY VIDEO and NO MUSIC, you need to set machine=tandy in dosbox.conf. Please do that and *then* comment :-)
Exin: The routine is as optimized as it is going to go; most people don't understand how slow 4.77MHz machines really are. Memory access times are so bad (4 cycles per byte, including opcode fetches) that a 4.77MHz 8088 is slower than a C64. I'm not kidding.
Here's the inner loop of the rotozoomer:
add cx,SI {ddx}
add DX,bp {ddy}
mov BL,ch {bx = 256*int(y)+int(x)}
mov BH,DH
mov al,[BX] {load a pixel from source}
{next pixel}
add cx,SI {ddx} {add the 'right' vector to the current}
add DX,bp {ddy} {bitmap coordinates. 8.8 fixed point}
mov BL,ch {bx = 256*int(y)+int(x)}
mov BH,DH
mov ah,[BX]
stosw {copy, advance to next dest. word}
All variables are in registers; writes to video memory are done at the largest machine size word (STOSW). It took me a long time to get things that optimized, so if you think you can do better, I would love to know how. I know I'm not the best coder out there, but this was one of the few effects I was proud of.
I will say this: My music routines need optimizing :-( It's faster without music playing.
Final version with source will be released in a week or so.
Here's the inner loop of the rotozoomer:
add cx,SI {ddx}
add DX,bp {ddy}
mov BL,ch {bx = 256*int(y)+int(x)}
mov BH,DH
mov al,[BX] {load a pixel from source}
{next pixel}
add cx,SI {ddx} {add the 'right' vector to the current}
add DX,bp {ddy} {bitmap coordinates. 8.8 fixed point}
mov BL,ch {bx = 256*int(y)+int(x)}
mov BH,DH
mov ah,[BX]
stosw {copy, advance to next dest. word}
All variables are in registers; writes to video memory are done at the largest machine size word (STOSW). It took me a long time to get things that optimized, so if you think you can do better, I would love to know how. I know I'm not the best coder out there, but this was one of the few effects I was proud of.
I will say this: My music routines need optimizing :-( It's faster without music playing.
Final version with source will be released in a week or so.
Thanks for the code, it's tight and interesting :)
A faster and different code is how, I think (I am not sure but I guess) some CPC coders are doing the rotozoomer, which although makes their rotozoomers ugly and less accurate when zooming close. They don't add the dx and dy each time but they have many different unrolled codes for each gradient. Since in one frame you have the same ddx and ddy for each scanline you render when moving on X, then they make an unroll code working for one scanline where instead of add cx,si and add dx,bp for example, they have most of the times on inc ch or one inc dh or nothing, mixed, because during the interpolation one of them if not two might change by one or at some pixels there could be no change (only if the precalculated unrolled codes are for the rotozoomer frames closer, more zoomed in to the viewer). Although it needs a lot of precalcs (if in a rotozoomer looping animation there are 200 different gradient/zoom combinations you need 200 unrolled code precalcs for one scanline of pixels) and is kinda ugly when it zooms in. It's a bit strange to explain but I think this is how they do it a bit faster than my current attempts on the CPC.
A faster and different code is how, I think (I am not sure but I guess) some CPC coders are doing the rotozoomer, which although makes their rotozoomers ugly and less accurate when zooming close. They don't add the dx and dy each time but they have many different unrolled codes for each gradient. Since in one frame you have the same ddx and ddy for each scanline you render when moving on X, then they make an unroll code working for one scanline where instead of add cx,si and add dx,bp for example, they have most of the times on inc ch or one inc dh or nothing, mixed, because during the interpolation one of them if not two might change by one or at some pixels there could be no change (only if the precalculated unrolled codes are for the rotozoomer frames closer, more zoomed in to the viewer). Although it needs a lot of precalcs (if in a rotozoomer looping animation there are 200 different gradient/zoom combinations you need 200 unrolled code precalcs for one scanline of pixels) and is kinda ugly when it zooms in. It's a bit strange to explain but I think this is how they do it a bit faster than my current attempts on the CPC.
Quote:
then they make an unroll code working for one scanline where instead of add cx,si and add dx,bp for example, they have most of the times on inc ch or one inc dh or nothing, mixed, because during the interpolation one of them if not two might change by one or at some pixels there could be no change
Also,. with this logic more stuff can be removed, if from one pixel to the next when adding the gradient doesn't change the high value (you are still at the same U,V on the bitmap) then you don't need to reread the pixel since it's the same. I mean, you can remove more code than only the ddx, ddy adds in many places (and that always depends if the rotozoomer is closer to the viewer, less incs and rereads of pixels). Anyways :)
Yeouch, I'm not sure I could live with myself with so many unrolled loops :) The only unrolled loop I have is 40 instances of the above snippet, for a single 80-byte-wide scanline. But that's an interesting concept, thanks for sharing it.
Someday I'll write a full-fledged 8088 demo with at least 10 effects... I may be bothering the C64/CPC/speccy people when that time comes ;)
Someday I'll write a full-fledged 8088 demo with at least 10 effects... I may be bothering the C64/CPC/speccy people when that time comes ;)
Cool! I am looking forward to your demo :)
we need a capped.tv version :)
video?
neat
=D
enjoyed watching it just as much as I enjoyed watching him code it. Wish he had been at the party this year.
Keep em coming!
hm
submit changes
if this prod is a fake, some info is false or the download link is broken,
do not post about it in the comments, it will get lost.
instead, click here !