| |
HCL
Registered: Feb 2003
Posts: 716 |
Screen limits
Once when i got myself a C= monitor, I made some tests to see what the actual limits were. Keeping in mind all the bugs i left in Royal Arte, after this i would never have to leave any visual bugs because of not seing them.
But now in EMU-age, the same horrible bugs appear again in many demos. Vice only shows 272 x 384 pixels, and people appearantly start to think that's the way to go. And it suxx big time!
So when i found my old screen tests yesterday, i thought maybe i should put this up here. I also had some info about sprite-limits in the borders. Let's get started.
Screen limits
-------------
Vertically:
First visible line: 8 (d012 = 8)
Last visible line: 12b (d012 = 2b)
That makes 292 visible lines totally.
Transfered to sprite positions we get..
spt-pos 12a: one line visible in lower border.
spt-pos 12b: one line visible in upper border.
Horizontally:
Left border: 48 visible pixels (6 chars).
Right border: 36 visible pixels (4.5 chars).
That makes 404 pixels, right.
Sprite bugs in left border:
All sprites invisible at positions 1f8-1ff.
spt7 invisible at pos <= 1ce.
spt8 invisivle at pos <= 1ee.
Sprite bugs in right border:
spt1 stretch bug at pos >= 14b.
spt2 stretch bug at pos >= 15b.
Bug above first line at pos => 163: spt 3,4,5.
Bug on last line at pos => 164: spt 3,4,5.
Ok. I think that's all. Does anyone have other specs? Please don't post if you have a lowsy TV-set, they always sukk. Did i get those sprite-bugs correctly? Sounds totally wierd :). And finally: DON'T RELEASE before you checked your demo against this spec >:E. |
|
... 103 posts hidden. Click here to view all posts....
|
| |
tlr
Registered: Sep 2003
Posts: 1702 |
Quote:There are now two important things that the people behind VICE should fix: 1. Sort out the VICE screen size and 2. Sort out the music to screen timing (as some demos suffer as a result).
As for 2 there is not much to do except for low latency drivers like ASIO.
Remember that a true emulation must also be interactive so long prebuffering of the graphics isn't what you want.
You could have a switchable mode for non-interactive, perfect sync execution of a program though. |
| |
Krill
Registered: Apr 2002
Posts: 2822 |
It can still be interactive with a frame buffer, the latency is just higher.
Wile: Looks like my border patch will be added to the next release of VICE. |
| |
Wile Coyote
Registered: Mar 2004
Posts: 634 |
Quote: It can still be interactive with a frame buffer, the latency is just higher.
Wile: Looks like my border patch will be added to the next release of VICE.
Will the border patch allow VICE to show the whole screen? if so, great! |
| |
Krill
Registered: Apr 2002
Posts: 2822 |
There are 3 options: normal borders, full borders, and debug borders. Full borders shows as much as you see on a monitor, and debug borders shows the full 63x8 * 312 pixels area, which is impossible with a real device. |
| |
Wile Coyote
Registered: Mar 2004
Posts: 634 |
Quote: There are 3 options: normal borders, full borders, and debug borders. Full borders shows as much as you see on a monitor, and debug borders shows the full 63x8 * 312 pixels area, which is impossible with a real device.
Full borders sounds good. I remember seeing Krestage, and theres a part with 8 'KRESTAGE' sprites in the lower border complete with 2 hires up scrollers (also in the lower border). Anyway, I could believe how much info was missing from the screen when using VICE. The lower 30% of the 'KRESTAGE' sprites were not being diplayed.
As for a debug option. Well I'm sure that will come in handy for the coders. I'm no coder, although I did get some rasters colour cycling after someone sent me some code, to show me how. It made zero sense to me. I'm sure I would understand C64 code if there was a book avaialble explaining how to, in logical terms (my type of logic :). |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: sideborder stuff doesnt impresses me anymore like back then. Come on, adding a sta $d016 stx $d016 to your code is really so cool ? How about coming up with something new instead of putting one of the effects seen a thousand times before to the borders because thats so "cool" ?
Oh my, oswaldb0gar is on the loose again! <:-)
Border KICKS ASS, always has, alway will! *anything* looks *so much* better, more impressive and cooler if you put it into the border! It's a fact, and there'*s no denying, hehe... I've gotten SO MUCH positive feedback over the years for anything we ever made that goes into the border i think I can say with confidence that you're pretty much alone with your opinion..
Of course I don't mind new ideas either, but I do not see at all how that is an "either or" matter!... Where's the law that says you can't put new effects into the border, only old ones? <:-)
|
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
Quote: Oh my, oswaldb0gar is on the loose again! <:-)
Border KICKS ASS, always has, alway will! *anything* looks *so much* better, more impressive and cooler if you put it into the border! It's a fact, and there'*s no denying, hehe... I've gotten SO MUCH positive feedback over the years for anything we ever made that goes into the border i think I can say with confidence that you're pretty much alone with your opinion..
Of course I don't mind new ideas either, but I do not see at all how that is an "either or" matter!... Where's the law that says you can't put new effects into the border, only old ones? <:-)
Come on DeeKay... that was AGEs ago... |
| |
Ninja
Registered: Jan 2002
Posts: 404 |
DK: Geez, you are referring to a 4 years old statement that Oswald relativated since then? Besides, there is no per se, as you mentioned. There are parts which do not look better if you extend them in x a bit for the price of cutting them more than half in y, despite all technical complexity. If you manage to have them in the borders without drawbacks, that's way cool, of course. |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
Quoting HCL
Sprite bugs in left border:
All sprites invisible at positions 1f8-1ff.
I just realized that this is probably because 63 cycles*8 pixels/cycle = $1f8 pixels. If this is true then it won't happen on NTSC. Does anybody know what sprite bugs there are on NTSC? |
| |
Krill
Registered: Apr 2002
Posts: 2822 |
On 65-cycle NTSC machines you have a sprite gap instead.
65 * 8 = $0208, so there is a range of 8 pixels in which you cannot place sprites.
(Of course, you can still reach into and cover the gap with sprites, the gap just applies to their leftmost 8 pixels.) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 - Next |
