| |
HCL
Registered: Feb 2003
Posts: 717 |
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....
|
| |
Mantiz
Account closed
Registered: Apr 2006
Posts: 36 |
Anyone else with the skills and the right tools willing to help doing this compile for the rest of us? Obviously we are at least a few who would use this for various reasons, so it won't be done in vain. I can even get it hosted if that is the problem.
I don't think the use of a certain tool should have to be justified to anyone, I would for example just out curiosity use this to see what's going on behind the scenes, so to speak. And to exactly know where your raster is outside the visible screen is maybe not the most usable feature but I can't see what would be wrong with it. Usually it's good to know where you have your beam. :) |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
I for one would like to see all 312 lines, so I could see how much rastertime all subroutines used.
|
| |
Krill
Registered: Apr 2002
Posts: 2854 |
Hmm ok, i am slowly getting convinced to add that option. So the VIC-II settings dialogue will contain a radio button group where you can choose between "Normal Borders", "Full Borders", and "Debug Borders". :) |
| |
WVL
Registered: Mar 2002
Posts: 886 |
Quote: Hmm ok, i am slowly getting convinced to add that option. So the VIC-II settings dialogue will contain a radio button group where you can choose between "Normal Borders", "Full Borders", and "Debug Borders". :)
I rather have single-frame advance. By pressing N or something. Not Ctrl-Alt-shift-P or something (hurrah for linux-born VICE :P) |
| |
Krill
Registered: Apr 2002
Posts: 2854 |
I already said it's on my list. :) |
| |
Ninja
Registered: Jan 2002
Posts: 407 |
Krill: I know my example with the stable raster was not a good one. I know how to put it into the visible area. I know some pros and cons about open-source development ;)
Sorry, I just got carried away cause I occasionally see developers spending 10 minutes arguing about not implementing something cause they don't see any use of it, instead of 5 minutes implementing it. Furthermore, I believe in Murphy, that exactly this feature is needed somewhen... But I know that mileages do vary ;) Nice to see it on your list after all! |
| |
Krill
Registered: Apr 2002
Posts: 2854 |
It's not like adding that took me less time than argueing about it, though. :)
Anyways, i also added a no borders option, as Yago suggested, for the gamers among you. :)
Now just some cleaning left, and the patch will be sent to the VICE team. |
| |
Krill
Registered: Apr 2002
Posts: 2854 |
Okay, so i sent the patch to the VICE team last night. Anybody who can't await the next version can have it forwarded, just tell me. |
| |
JackAsser
Registered: Jun 2002
Posts: 1994 |
@krill: Telling you... email. :D |
| |
JackAsser
Registered: Jun 2002
Posts: 1994 |
I love debugborders! :D Try, Cycle, Deus ex, The wild bunch etc... Very interesting stuff going on in the borders. :D
However Gunnar, the x128 build is broken and the cmd-line interface is b0rked. -***borders have NO effect. +***borders <value> have all the same effect. I.e. value==0 => VICE, ==1 => GAMERS, ==2 => NORMAL, ==3 => DEBUG.
Now I COULD fix these things myself but I don't care so much honestly, it works for me as it is. Just wanted you to know about the bugs.
/Andreas
Snip from config.log:
./configure --enable-fullscreen
uname -m = i686
uname -r = 2.4.22-10mdk
uname -s = Linux
uname -v = #1 Thu Sep 18 12:30:58 CEST 2003
configure:2361: gcc --version </dev/null >&5
gcc (GCC) 3.3.1 (Mandrake Linux 9.2 3.3.1-2mdk)
x128 errors:
if gcc -DHAVE_CONFIG_H -I. -I. -I../../src -I../../src/arch/unix -I../../src -I../../src -I../../src/drive -I../../src/c64 -I../../src/sid -I../../src/tape -I../../src/vicii -I../../src/vdc -I/usr/X11R6/include -g -O2 -DNO_REGPARM -Wstrict-prototypes -Wall -Winline -MT c128.o -MD -MP -MF ".deps/c128.Tpo" -c -o c128.o c128.c; \
then mv -f ".deps/c128.Tpo" ".deps/c128.Po"; else rm -f ".deps/c128.Tpo"; exit 1; fi
c128.c: In function `machine_change_timing':
c128.c:760: error: too few arguments to function `vicii_change_timing'
|
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 - Next |
