Jump to content
IGNORED

Elite must be ported to A8


Philsan

Recommended Posts

On an unrelated note, remember that GR.8 on real hardware yields superior image quality when run in "inverse" mode, with the default colors swapped so that you clear bits to light them up instead of the other way around.

Very interesting. What do you exactly mean by "superior quality"?

For the same color settings, pixels lit up this way are output somewhat sharper and brighter. Years ago someone (JD Potter, I think) verified this on real hardware with an oscilloscope. I can't find the post right now, but I vaguely remember something about an improved duty cycle for lit pixels.

 

This technique also allows using player/missile underlays to make some pixels appear brighter or darker (FlickerTerm 80 used this to implement the VT100 bright text atribute).

Link to comment
Share on other sites

If it was the case, I'd guess most likely it would have to do with something internal to GTIA.

 

It could be that the 1->0 transitions occur quicker than 0->1 transitions which might mean that the luma change occurs slightly quicker going from PF1->PF2 compared to PF2->PF1.

 

Might give it some testing at some stage with the oscilloscope.

 

Of course, there's the known issue with slow transitions when going from Luma value 8 to another value although I doubt it would be relevant in this case, as it occurs regardless of which Playfield registers are involved.

Link to comment
Share on other sites

Thanks ZylonBane. Do you remember any other keywords that might help find it? Who else has participated in the discussion?

 

It could be that the 1->0 transitions occur quicker than 0->1 transitions which might mean that the luma change occurs slightly quicker going from PF1->PF2 compared to PF2->PF1.

 

From what has been said, it seems that both PF1->PF2 and PF2->PF1 transitions go quicker if PF1's luminance is lower than PF2's. Right?

 

Of course, there's the known issue with slow transitions when going from Luma value 8 to another value

AFAIK it happens only in the GTIA 1 color-16 lums mode, is that right?

Link to comment
Share on other sites

The theory seems to indicate that hires bitvalue 0 is displayed with longer duty cycle than bitvalue 1.

 

The actual colours you have set should make no difference. Of course, that luma issue could come into play, but in testing it would probably be best to use combinations that avert that problem.

 

The luma transition to/from 8 problem occurs in any mode... it's just that most demos that show horizontal luma bars are done in GTIA modes.

Link to comment
Share on other sites

Well, I don't see why it would matter to swap palette and go to inverse video gfx. When we draw a vertical bar of pixels:

 

00001110000

00001110000

00001110000

 

then we can swap to inverse:

 

11110001111

11110001111

11110001111

 

In both cases we have a zone of 0 -> 1 and 1 -> 0 transitions, thus PF2 -> PF1 and PF1 -> PF2 transitions. Then we can swap the PF1 and PF2 palette values. Only thing that differs is the exact location of these zones. So, in normal gfx a 'sharper' line will take place on the right part of the bar, and in inverse gfx it will be on the left part? Does this really make any difference? Or didn't I understand it correctly?

 

 

Isn't this an NTSC issue anyway?

 

 

EDIT:

Or can we interpret "bit0 (in theory) has longer duty cycle" as "a vertical line of 1 pixel width gets wider duty cycle in both directions?", i.e. the pixel gets wider into the right AND into the left direction??

Edited by analmux
Link to comment
Share on other sites

I'd have tried it by now, but the 130XE and oscilloscope have to come out.

 

A capture card's resolution won't be any good... 720 pixels horizontally, which in reality translates to less than 2 pixels per single Atari hires pixel (my card can actually display practically all of the Widescreen mode pixels the Atari could generate).

 

I don't think a hi-def TV would be much help either. They tend to do all sorts of filtering and scaling stuff, so you'd be getting something different to what's actually being generated.

Link to comment
Share on other sites

I took a quick look with my 800 XL. I've a great 300Mhz scope to pull out myself, but didn't yet.

 

Anyway, on the capture card, there are some minor differences on the pixels, when using the HD capture on composite. On a SD capture, I can't tell any real difference.

 

On the analog SONY SD TV, with the filters off, inverse pixels are more consistent in size. I can see a difference between an odd pixel and an even one, with the default colors. On a monochrome screen, they appear the same to me. On a color screen, they are different and this can be seen when the pixel is bright far easier than it can when the pixel is dark.

 

I'll give this a closer look on the HDTV later on.

Edited by potatohead
Link to comment
Share on other sites

If you always draw the full screen into the buffer, ofcourse it will not get any slower than drawing directly to the screen memory. This is what I wrote aswell.

 

If you wrote that *I* missed it, or it wasn't sufficiently clear. Great!

 

It's the problem with - re-using graphics - to save time, where double buffering is useless. Because you have to change graphics in two areas of the memory.

 

Yes, there can be some additional memory use required to maintain two seperate "lists" of which parts of the screens need to be changed on each buffer, but this is trade-off that the programmer is doing. Trading extra memory usage to eliminate artifacts and tearing to compensate for a slow draw routine (one that cannot be completed in 1/60 of a second). Extra CPU usage is debatable, but I guess that depends on how the routines for managing the two lists of "things to be change" is managed. I wouldn't call it useless though-it serves a purpose in the right circumstances. Double buffering is a pretty common technique in game programming, especially on platforms that aren't memory crippled.

Link to comment
Share on other sites

  • 1 year later...

But it's much faster to have a line erase routine. It's just modified Bresenham logic without updating the screen until the address changes, then write 0 to it. You don't have to worry about accidentally erasing something since you are erasing everything.

Testing for an address change would still be slow. The fastest way would be for the line-erase routine to treat the screen as 32 pixels wide, eg-- one byte per pixel. Then the only overhead would be the up-front cost of dividing each X-coordinate by 8, which is cheap as-is, but could be made even cheaper with a lookup table. This would also have the advantage of the algorithm completing in up to 8 times fewer iterations, depending on how horizontal the line is.

Any change in Y would require an address change, and if x/8 changes the address changes. I didn't mean calculate and test the actual address itself. You are basically saying the same thing.

 

I would have replied sooner but I didn't see that post until today.

Link to comment
Share on other sites

It would be better to campaign outside Mark (Wrathchild) house but I think he wouldn't appreciate naked men (perhaps naked girls if he isn't married...). :D

LOL! As I'm in the Czech Republic at the moment my better half would probably welcome the display ;)

Kids would have to have gone to Summer Club or grandparents first though!

 

Here's where I'd got with the BBC port but I'd like to go back to the C64 port at some point, but real-life is requiring my attention for a good while.

  • Like 1
Link to comment
Share on other sites

The theory seems to indicate that hires bitvalue 0 is displayed with longer duty cycle than bitvalue 1.

 

The actual colours you have set should make no difference. Of course, that luma issue could come into play, but in testing it would probably be best to use combinations that avert that problem.

 

The luma transition to/from 8 problem occurs in any mode... it's just that most demos that show horizontal luma bars are done in GTIA modes.

 

I have observed with 100% certainty that on my NTSC 600XL the luma pulse width of even-column pixels is different than odd-column pixels; the difference is significant and visible. My hypothesis is that the cause is due to the OSC signal not being 50% duty cycle like it should be but I don't have the equipment to verify that. My NTSC XEGS did not seem to have that effect last time I looked; since it has FREDDY which divides down the 14MHz signal, it should be much closer to 50% so that seems to support the hypothesis.

 

Other than that I have never observed the effect of 1 being different from 0 - at least not on any of my hardware.

Link to comment
Share on other sites

OK Mark, we have to find another why to convince you.

Why Atarians never win EuroMillions lottery to remove programmers real-life problems?

 

 

Wasn't last week a switzerlang family that win the EuroMilions?

You have to check because they probably have any relationship with you?

(Here on my Parents father and Mother two Birnplaces all people are Parents in some degree ;) )

I was just saying that 3or4Hours ago to a friend that I would need to bet in EuroMillions but sadly one more time I lost the Hour to bet :x .

Edited by José Pereira
Link to comment
Share on other sites

OK Mark, we have to find another why to convince you.

Why Atarians never win EuroMillions lottery to remove programmers real-life problems?

 

 

Wasn't last week a switzerlang family that win the EuroMilions?

You have to check because they probably have any relationship with you?

(Here on my Parents father and Mother two Birnplaces all people are Parents in some degree ;) )

I was just saying that 3or4Hours ago to a friend that I would need to bet in EuroMillions but sadly one more time I lost the Hour to bet :x .

I think it was a British person but unfortunately not an Atarian!

Like said moths ago, if I'll win a lottery I will pay the best coders to make the games missing in A8 library.

I would need a graphic converter like you too!

 

But, first of all, I should play lotteries to have a chance to win...

Link to comment
Share on other sites

I think it was a British person but unfortunately not an Atarian!

Like said moths ago, if I'll win a lottery I will pay the best coders to make the games missing in A8 library.

I would need a graphic converter like you too!

 

But, first of all, I should play lotteries to have a chance to win...

 

It was a Scottish couple who won the other week.

 

With that amount of money I'd have my own Atari games programming company also, they'd make a loss but who cares?

Link to comment
Share on other sites

I think it was a British person but unfortunately not an Atarian!

Like said moths ago, if I'll win a lottery I will pay the best coders to make the games missing in A8 library.

I would need a graphic converter like you too!

 

But, first of all, I should play lotteries to have a chance to win...

 

It was a Scottish couple who won the other week.

 

With that amount of money I'd have my own Atari games programming company also, they'd make a loss but who cares?

I know a programmer that has a racing game to finish.

Perhaps you could hire him!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...