Sub-pixel accuracy is a myth. Only thing you have do is to set BLTAPT to 4(dy-dx).
category: residue [glöplog]
@Laffik 2023-04-07
Thanks a lot for the insights.
Sure, empiricism is integral to science - I call it the fun part. All well and good,
but that's only half the story -> true(!) science covers the subsequent
interpretation and explanation of the made observations.
And as you like subtle comments ;-)
@Laffik / 2023-04-04
Moving your magic 4(dy-dx).w into $dff052 should be even more accurate
(giggle).
Cheers
Thanks a lot for the insights.
Sure, empiricism is integral to science - I call it the fun part. All well and good,
but that's only half the story -> true(!) science covers the subsequent
interpretation and explanation of the made observations.
And as you like subtle comments ;-)
@Laffik / 2023-04-04
Quote:
Tah! Dah! The solution is: BLTAPT ($dff050) has to be set, just like
BLTAMOD, to: 4*(dy-dx). Not to 4*dy-2*dx, what's printed everywhere.
Moving your magic 4(dy-dx).w into $dff052 should be even more accurate
(giggle).
Cheers
$dff050 - long word. Amiga is big endian (or Winnetou, if you wish) - greater bits lands at lower address.
If you try to troll you shoud know what you say. you insult yourself other way.
"true science..." buterly buttrer...
If you try to troll you shoud know what you say. you insult yourself other way.
"true science..." buterly buttrer...
@Laffik added / 2023-04-08 13:26:43
I explicitly wrote .w, so why using .l to $dff050 if .w to $dff052 is possible?! Hope
you understand.
Are you human? Something is strange here?! Anyway, thanks for the entertaining
and a bit scary conversation.
I explicitly wrote .w, so why using .l to $dff050 if .w to $dff052 is possible?! Hope
you understand.
Are you human? Something is strange here?! Anyway, thanks for the entertaining
and a bit scary conversation.
Lol @ROG_VF, I had the same feeling :) I must commend on your patience here...
human... no. not since it started to mean "innumerati". I am superhuman. Titan. Son of a hoe and the devil.
Buehehehhe....
Buehehehhe....
The dude tries to affect the Demoscene, it seems.
THIS will affect demoscene in 2024!!!
Binary adding of polygons by Blitter.
Pink are sum components, overflow is green.
WhoTF cares about subpixel accuracy if the resulting releases look like a colorblind individual designed them. :)
mr. esthetist? no head for economy, though. vulgar and explicit colours attracts millions of customers to shops. how would it suppose to look? ordinary grey? banal basic colours?
there's no other esthetics nowadays apart from vulgarity, ordinarity and banal. I am not the God Creator. Or designer. I am coder. Most of all, this fusion of vivd green and pink amazes me.
there's no other esthetics nowadays apart from vulgarity, ordinarity and banal. I am not the God Creator. Or designer. I am coder. Most of all, this fusion of vivd green and pink amazes me.
It's Mr. Aesthetics, please. My pleasure.
To me it seems like from what Laffik wrote (-> e.g. missed points, skipped lines)
that his routine doesn't work properly with 4dy-2dx and because of that he came
to the false conclusion that subxpixel precision is strictly required for filled vectors.
Then he desperatley fiddled around with and exchanged register settings and
accidentally found out that 4(dy-dx) - for whatever reason - works. Would be
revealing to see how the output looks with 4dy-2dx.
P.S.: Hope you are aware of where the titans ended up. Fortunately, the parental
combination you specified excludes being a titan.
Kindergarten!
that his routine doesn't work properly with 4dy-2dx and because of that he came
to the false conclusion that subxpixel precision is strictly required for filled vectors.
Then he desperatley fiddled around with and exchanged register settings and
accidentally found out that 4(dy-dx) - for whatever reason - works. Would be
revealing to see how the output looks with 4dy-2dx.
P.S.: Hope you are aware of where the titans ended up. Fortunately, the parental
combination you specified excludes being a titan.
Kindergarten!
goddamn... it's "pouet". indeed dudes more skilled in poems, belletristics and mythology than in coding. what couold I expect.
I don't care how titans ended, because I am not a titan. Don't you differ imaginary layer and real layer? Asking if I am human? Sort your disorder...
Anyway, for your approval, ladies and gentlemen, for your enjoyment:
Wrong BLTAPT:
Line doesn't draw on top of green pixel causing various errors depending on angle of drawing. sometimes happen that draws odd number of pixels in a line, causing wrong fill:
Correct BLTAPT:
doubtful pleasure speaking to you...
I don't care how titans ended, because I am not a titan. Don't you differ imaginary layer and real layer? Asking if I am human? Sort your disorder...
Anyway, for your approval, ladies and gentlemen, for your enjoyment:
Wrong BLTAPT:
Line doesn't draw on top of green pixel causing various errors depending on angle of drawing. sometimes happen that draws odd number of pixels in a line, causing wrong fill:
Correct BLTAPT:
doubtful pleasure speaking to you...
Thanks for the image. It's exactly as I expected. There is somewhere an error in
your routine. Thanks for the proof :-)
your routine. Thanks for the proof :-)
There's error in line drawn right? Dodgy logic. Not my cup of t.
Did some tests with a filled vector routine that runs perfectly fine with 2dy-dx in
$dff052. Observation: Using 2(dy-dx) works, too. Even writing #0 to $dff052
works.
Another interesting(?) finding, or maybe old hat?: Testing for if signflag (bit #6) in
$dff042 has to be set seems to be dispensable, i.e., no difference and no visual
negative impact regardless of whether signflag (bit 6) is permanently set or not.
Made me scratch my head. Maybe someone else could confirm and explain?
@Laffik: It's very difficult not to feel insulted by your grumble kind of humour; at
least I hope it's intended to be humorous :-)
$dff052. Observation: Using 2(dy-dx) works, too. Even writing #0 to $dff052
works.
Another interesting(?) finding, or maybe old hat?: Testing for if signflag (bit #6) in
$dff042 has to be set seems to be dispensable, i.e., no difference and no visual
negative impact regardless of whether signflag (bit 6) is permanently set or not.
Made me scratch my head. Maybe someone else could confirm and explain?
@Laffik: It's very difficult not to feel insulted by your grumble kind of humour; at
least I hope it's intended to be humorous :-)
Dude! Reality check! Please!
Even organizers have displayed a message in front of your release in the compo that it's (told the polite way) technically crap.
:D
Even organizers have displayed a message in front of your release in the compo that it's (told the polite way) technically crap.
:D
Last comment was obviously directed in @Laffik's way.
And BTW:
If you would show off a decent attitude I even would help you out with some graphics and design advise for your releases.
Just be nice to the people and shut down your arrogance and you will get so much more out of the demoscene, like: Help! Advise! Friends!
If you would show off a decent attitude I even would help you out with some graphics and design advise for your releases.
Just be nice to the people and shut down your arrogance and you will get so much more out of the demoscene, like: Help! Advise! Friends!
it's not a crap, it's just DMAWait that was set to 100 ticks instead of 300.
On slower emulation, cycle exact, on WinUAE - music stutters. but not on hardware.
I sent it to a fiend for testing on hardware Ami. Tested it. It's is fine. Especially player. I've got it on vid. And it was 30/50MHz. 60/66MHz stuttered? Could be if it was WinUAE.
Phong is slow, like any phong. anything without chunky to pixel. Phonk works on planar. what to wonder at?
Could be only that executable assembled on WinUAE doesn't go on hardware Ami, cause of lack of compatibility - could be that emulation is not exact or ROMs or smth (even though I've got propper AmigaForever set of ROM images). IDK.
Howk!
On slower emulation, cycle exact, on WinUAE - music stutters. but not on hardware.
I sent it to a fiend for testing on hardware Ami. Tested it. It's is fine. Especially player. I've got it on vid. And it was 30/50MHz. 60/66MHz stuttered? Could be if it was WinUAE.
Phong is slow, like any phong. anything without chunky to pixel. Phonk works on planar. what to wonder at?
Could be only that executable assembled on WinUAE doesn't go on hardware Ami, cause of lack of compatibility - could be that emulation is not exact or ROMs or smth (even though I've got propper AmigaForever set of ROM images). IDK.
Howk!
Quote:
it's not a crap, it's just DMAWait that was set to 100 ticks instead of 300.
And you seriously think that increasing the WAIT value to 300 will have any effect on fast machines? The DMA "wait" IS crap, as simple as that, as it is just a CPU dependent "empty" dbf loop. Besides, there is a lot more wrong with the replayer code resp. the way you are using it, which easily explains the problems. Drop the attitude and start fixing your code!
fifty quid for your order sir! fancy buy-one-get-one-for-free? (bogoff...)
i don't fix my code! it is written, what I wrote. I am developing Blitter procedures for next year's edition.
CU!
i don't fix my code! it is written, what I wrote. I am developing Blitter procedures for next year's edition.
CU!
I'm looking forward to more high-quality code from you. I can hardly wait.
Quote:
next year's edition
I have the slight inkling that that might not happen on an Easter party nor any party with Charlie as compo orga, since he in so many words ("For now...") told you that if the next iteration of your "project" won't work on the machine it will get disqualified.
But who am I, standing in the way of a perfectly hysterical train wreck?
overmisinterpretation...
(I had to smith-up neologism for it, as there's no right word for this way of interpretation).
Charlie said very positively, that to keep party tradition, of lack of disqualifications, is the aim. And praise to him for that.
terrible pessimist you are...
sometimes happens, that demo (it was .mod player!, to be precise!) flips. While hardly anybody has access to 060/66MHz? Who of submitting had? You like dropping gridlocks. Pervert!
(I had to smith-up neologism for it, as there's no right word for this way of interpretation).
Charlie said very positively, that to keep party tradition, of lack of disqualifications, is the aim. And praise to him for that.
terrible pessimist you are...
sometimes happens, that demo (it was .mod player!, to be precise!) flips. While hardly anybody has access to 060/66MHz? Who of submitting had? You like dropping gridlocks. Pervert!
If you don't have access to an 060 you really shouldn't be making stuff that requires one to run properly, unless you really know what you're doing (which you very clearly don't). Stingray already gave you some good tips on how to fix your code, so drop the shitty attitude and actually listen to the advice you're given.
