help, VGA Box = blinking screen
JumpKick
It seems to work, speeds up my game to 60 herz (soccer players run faster,
cars drive faster, music seems to go faster too, sounds really funny) and
the picture quality in games that support it is good.
I have a big problem though. The VGA box causes the screen to go black for
1- 2 seconds every now and then. This is a real problem in-game. It's not
the games though, the VGA box also does the blinking thing when it's in the
VGA boot disk menu.
I've disconnected and reconnected the cabling, to no avail. Does anyone know
what's going on?
Martin Wilson
Well it sounds like the monitor doesn't like syncing down to base vga
mode. Note the vga output of these boxes is slightly less than normal
vga I believe as the ps2 outputs 640x400 I think instead of 640x480. I
think the ps2 does modes like 320x200, 320x400 (ridge racer v) and
640x400.
JumpKick
"Martin Wilson" <mart...@ukonline.co.uk> schreef in bericht
news:o1cdkv01ck8e76jis...@4ax.com...
but I also have a Dreamcast VGA box, and it works perfectly?
Martin Wilson
>
>
>but I also have a Dreamcast VGA box, and it works perfectly?
Dreamcast is nearer VGA standard as it does do a 640x480 resolution.
Even so some monitors do play up with dreamcast vga boxes too. A
friend had a LG monitor and that wouldn't work with a dc vga box
properly. I think it lost sync occasionally. If you can try the vga
lead on another vga monitor and it works then it will be your monitor.
Preferably try an older vga monitor which will more likely work with a
lower refresh rate vga signal. Basically theres nothing much in these
leads anyway. All they do is short a pin to tell the ps2 that a
vga/progressive signal is required with two syncs. Theres not much in
the way of electronics in them to go wrong.
JumpKick
"JumpKick" <*dontspam*soe...@zonnet.nl> schreef in bericht
news:1Ar1b.117687$lA6.4...@castor.casema.net...
thanks for the input
I tried the box with an older 15" VGA monitor and it works fine now.
Pity it won't work on my 19" (well.... it works, but with dark screen
interruptions).
I've noticed that in a lot of games, the VGA box cuts the image on the top
and bottom of the screen!!!That's quite dissapointing, I can't see stamina
meters on the bottom of the screen for example. And I hope that some day
games will come out that can just self-boot in progressive scan mode instead
of relying on the VGA boot disk, which can get annoying.
Image quality is great though.
Martin Wilson
>thanks for the input
>
>I tried the box with an older 15" VGA monitor and it works fine now.
>
>Pity it won't work on my 19" (well.... it works, but with dark screen
>interruptions).
>
>I've noticed that in a lot of games, the VGA box cuts the image on the top
>and bottom of the screen!!!That's quite dissapointing, I can't see stamina
>meters on the bottom of the screen for example. And I hope that some day
>games will come out that can just self-boot in progressive scan mode instead
>of relying on the VGA boot disk, which can get annoying.
>
>Image quality is great though.
>
Sounds like its cutting off top and bottom of overscan screens or
possibly pal resolution screens. I suppose its something it has to do
to get the screen VGA compatible.
JumpKick
I've looked it up on the blaze website, it is a known issue with the
majority of games it seems!
Mark ellerman
"Martin Wilson" <mart...@ukonline.co.uk> wrote in message
news:5gvjkvkdldhm60127...@4ax.com...
>
> >
> >
> >but I also have a Dreamcast VGA box, and it works perfectly?
>
>
> Dreamcast is nearer VGA standard as it does do a 640x480 resolution.
A DC is nowhere _NEAR_ VGA standard as it uses a low resolution tile based
system, to produce a fake/psuedo high resolution to fool the gullible! [much
like the PC/XBox/GC etc].
As a tile is designed to cover a larger area, a DC etc would be outputting
640/4 x 480 for a 4x1 tile which is a 1/4th of the true resolution that a
VGA screen is capable of.
VGA otoh, couldn't handle the output from Yabasic.. IE
OPEN WINDOW 640,512
Sorry if I've just pissed on your chips! :P
ammo...@cc.full.stop.helsinki.fi
> A DC is nowhere _NEAR_ VGA standard as it uses a low resolution tile
> based system, to produce a fake/psuedo high resolution to fool the
> gullible! [much like the PC/XBox/GC etc].
I suppose the Kyro based graphics cards which use practically the same
chips aren't really VGA either. In other words, what the fuck are you on
about?
-a
JumpKick
image. Never. also, the image you get is far from fulll-screen (varies per
monitor). Lukicly, my monitor can strecth out the picture very far. Sadly,
This still leaves borders at th etop or bottom of the screen.
I don't understand how this is possible with a 4:3 resolution of 648*480 (I
dont really understand your story about it not being truly that resolution,
sorry :) ) on a 4:3 screen.
Anyway, the PS2 VGA box has great picture quality but REALLY annoys me with
it's cutting off the top and bottom of the screen. Gr.
Simon F
> "Martin Wilson" <mart...@ukonline.co.uk> wrote in message
> news:5gvjkvkdldhm60127...@4ax.com...
> >
> > >
> > >
> > >but I also have a Dreamcast VGA box, and it works perfectly?
> >
> >
> > Dreamcast is nearer VGA standard as it does do a 640x480 resolution.
>
> A DC is nowhere _NEAR_ VGA standard
Sorry no. Apart from perhaps 1 or 2 early games that used 640x~240,
games use 640x480 on DC.
>as it uses a low resolution tile based
> system, to produce a fake/psuedo high resolution to fool the gullible! [much
> like the PC/XBox/GC etc].
I'm sorry to say that you don't know what you are writing about.
>
> As a tile is designed to cover a larger area, a DC etc would be outputting
> 640/4 x 480 for a 4x1 tile which is a 1/4th of the true resolution that a
> VGA screen is capable of.
>
Absolutely not.
A "tile" on PowerVR refers to a NxM pixel subsection of the
framebuffer - IIRC, on DC the tiles are 32x32 pixels. A 640x480
display is thus subdivided into 20x15 tiles. Each tile is then
rendered completely before moving on to the next tile.
There are several advantages to this approach which are described in
the white papers on www.powervr.com eg
http://www.powervr.com/pdf/TBR3D.pdf
> Sorry if I've just pissed on your chips! :P
Sounds like incontinence to me.
Mark ellerman
"Simon F" <sim...@my-deja.com> wrote in message
news:7f95c0fc.03091...@posting.google.com...
> "Mark ellerman" <its...@tiscali.co.uk> wrote in message
news:<bjkkom$k5jko$1...@ID-200061.news.uni-berlin.de>...
> > "Martin Wilson" <mart...@ukonline.co.uk> wrote in message
> > news:5gvjkvkdldhm60127...@4ax.com...
> > >
> > > >
> > > >
> > > >but I also have a Dreamcast VGA box, and it works perfectly?
> > >
> > >
> > > Dreamcast is nearer VGA standard as it does do a 640x480 resolution.
> >
> > A DC is nowhere _NEAR_ VGA standard
>
> Sorry no. Apart from perhaps 1 or 2 early games that used 640x~240,
> games use 640x480 on DC.
Erm.. I wasn't talking about _vertical_ resolution!
[Quote]
-->*a DC etc would be outputting 640/4 x 480 for a 4x1 tile*<--
I always gave the DC the benefit of the doubt vertically, otherwise I'd have
uses 2x2 tiles so it would have been 640/2 x 480/2 for 4:1 compression.
Good start.
> >as it uses a low resolution tile based
> > system, to produce a fake/psuedo high resolution to fool the gullible!
[much
> > like the PC/XBox/GC etc].
>
> I'm sorry to say that you don't know what you are writing about.
Well, that's a bummer, as I'll never get by on my looks.
> > As a tile is designed to cover a larger area, a DC etc would be
outputting
> > 640/4 x 480 for a 4x1 tile which is a 1/4th of the true resolution that
a
> > VGA screen is capable of.
> >
> Absolutely not.
*Absolutely not*, what? A tile by it's very NATURE is designed to cover a
larger area, if you have a 12'x12' area, you don't go ordering 144x 2'x1'
tiles, you order 72, likewise a 4'x1' tile = 36. The same thing with pixels,
the bigger the tile, the less resolution ie places where you can put the
tile! Simple logic!
> A "tile" on PowerVR
Lol! I'll repeat what I said earlier..
**********************
as it uses a low resolution tile based
system, to produce a fake/psuedo high resolution to fool the gullible!
[much like the PC/XBox/GC etc
************************
Well, heeeello Mr Gullible! Lol
>refers to a NxM pixel subsection of the
> framebuffer
But it's STILL a _tile_ Duh.. Do you REALLY _NOT_know the difference
between true bitmapped and tile based?
A framebuffer is merely a lump of RAM btw. So can you explain why anyone
would split RAM into smaller bits of RAM if the objective WASN'T to save on
memory? Duh!
>- IIRC, on DC the tiles are 32x32 pixels. A 640x480
> display is thus subdivided into 20x15 tiles. Each tile is then
> rendered completely before moving on to the next tile.
BWAHAHAHAHAHAHA!!
It's even WORSE than I thought! [If I believed you that is].
ME: The DC etc is bad because it uses a tile based system.
Mr Gullible: No it isn't you fool because it uses bigger tiles than you
quoted!
Go put your eye close to a TV or monitor son, you'll find that it's full of
little dots called pixels and each of these pixels have R,G & B sections.
Early 8Bit computers used to divide a resolution into matrix's also, they'd
divide for example a 256x192 screen into 32x24 8x8 sections, so that the 8
bit could save on memory/ VRam. The memory register would now contain a tile
pattern number, so instead of the computer having to address 49,152 memory
registers _individually_ as it would on a true bitmapped screen, it simply
had to load a character shape into a memory register and there were only
32*24= 768 of those. As the character shape was stored in a buffer elsewhere
in VRam, 49,152 memory locations as opposed to 768??. A bit of a saving eh?
A VGA/60Hz /NTSC would have a possible (640*480)= 307,200 possible places to
address [ie Video _Random_ _Access_ _Memory_] and each of those pixels can
have it's own RGB value, yet YOU think
that you can reduce this to 20*15 = 300 and yet is STILL be using a 60Hz
screen to it's full potential?
Do you also believe in Santa and the Easter Bunny too? Lol
Incidentally when I was using a 1/4 ratio, I was giving the DC the option of
having (640/4)*480 = 76,800 _independant_ possible places where a tile could
be placed, YOU'VE just reduced that to 300 and think that THAT'S an
friggin' improvement????
And *I* don't know what *I'm* writing about?
A TV/monitor screen is essentially memory and it's true bitmapped. There is
no earthly reason why a machine would actually use
TILES to display to a screen, if NOT to save on memory.. Ergo, a DC /XBox/
GC doesn't use a VGA screen to it's full capacity. Got it?
BTW. 32 is divisible by 4, which is what I presumed the tile size was [IE A
4X1tile]. This would give the DC /XBox etc 4:1 compression any more than
this, means it's using LESS than my estimated 1/4 of a VGA resolution, but
the fact remains that if you aren't using PIXEL coordinates, then you aren't
using a VGA screen to it's full potential.
When a tile is laid down, it's fucked on it's own as it already had to
have used it's RGB value to be seen, what happens is other tiles are then
laid down then logical /bitwise/ maths operators are applied between the
tile's RGB values to make colour run from one tile compartment to the next.
These colours are then picked up by the TV's RGB values which gives a FAKE
resolution. The reason that they are fake is that those pixel colours cannot
be addressed _individually_.
Also when you try to READ the memory address, you will be given the 24Bit
value of the _TILE_ which will be completely different from the actual
colours as the number will add up to the total of the texture. This is
because the tile is now containing 4 colours adding up to
1x 24Bit [perhaps less] value. A true bitmapped screen [ie a VGA/NTSC/PAL
/whatever] would allow 4x 24Bit numbers EACH with their own RGB value to be
placed in the same 4 pixels
As you can only use LOGICAL operators based on a tiles RGB values, the
output fake resolution is rendered [ie it's the actual rendering which
produces the resolution!]. This is because you can only produce
textures, which are colours with a similarity in RGB values, which is why
most DC/ XBox etc games look cutesy/cartoony, take a good look at Shenmue
especially in a night scene and if you're honest, Bugs Bunny wouldn't look
out of place there.
So using a 8x 4x1[= 32] tile/lines to create a fake
resolution of 32x 32 makes perfect sense as without adding the extra tiles
[and therefor other RGB values], you couldn't get the fake resolution or
pallette!
When you add up all the fake 32/4x32 resolutions you end up with 640x480!
Which is what I said in the first fucking place! Duh
Now look at the difference..
OPEN WINDOW 640,512
x=0: y=0: x3=640: y3= 512
For POLY= 1 to 5000
for POLYSIDECOL= 1 to 3: R= RAN(255): G= RAN (255): B=RAN(255)
SETRGB POLYSIDECOL, R,G,B: NEXT
x2=RAN(640): y2=RAN (512)
GTRIANGLE x,y TO x2,y2 TO x3,y3
Next POLY
The first thing to note is that as Yabasic can address 0-640 & 0-512, it's
true resolution is 641x513 (-1 so as not to count 0,0 twice).
The second thing to note, is that as the PS2/ Yabasic can address any memory
location within that resolution, it's a TRUE BITMAPPED screen, just like a
TV/Monitor. So in truth, you cannot GET any better!
As R,G & B are each in the range of 0-255 or &B0 - &B11111111 that's a
(256*256*256=) 16,777,216 colour pallette. As 16.7+ million is the limit of
the average human eye, do we actually need more?
Another thing to note, is that 641x513 x 24Bit, is up to and over, twice as
good as the media that Toy Story 2 was viewed on! Sony don't lie!
Now as the 2 pairs of diagonal coordinates of the _SINGLE_ triangle, is set
to it's
entire screen width, it's going to be pretty difficult to do this using a
tile based screen don't ya think? This is what Sony meant when they said
that each grain of wood, or each individual hair can be programmed
INDIVIDUALLY!
The 3rd pair of coordinates are randomly selected from a 640 and 512 number,
which means that there are 328,832 possible memory locations at it's
disposal, which is a bit more than 300 eh? There are also a possible 328,832
_independant_ RGB values on this screen also, which is 4x better than
76,800 eh?
GTRIANGLE, unlike FILL TRIANGLE [single colour] takes it's information for
it's sides, from 3 different colours and the PS2 automatically fills the
centre of the triangle, with a *graduated fill* [Gouraud shading?] using the
3 side colours as a reference. The PS2 will complete the 5000 poly's in the
blink of an eye, which is quite staggering really [esp from a Beginners
language] especially when you realise that if there were only 255 possible
colours per side the possibilities within that triangle would add up to
16.7+ million, but the PS2 is offering 16.7+ million PER SIDE, which adds up
to lots and VERY LOTS. ie..
4,722,366,482,869,645,213,696
Quite a few textures in that lot eh? lol
Seems that the PS2 doesn't have to render _square_ tiles, but can render
entire
_polygons_ of any size on a TRUE bitmapped screen, and at these sizes it's
only going to take 2 to fill an entire screen, which is higher resolution
than even a true Bitmapped VGA/ 60Hz can handle, let alone a shitty tile
based format being output by a DC/XBox/PC etc!
As for your 32x32 *framebuffer*.. This IS a frame buffer to the PS2,
[actually this is only one of 2 that Sony provides for beginners which are
called via SETDISPBUF/SETDRAWBUF] as it uses
TRUE VRAM which is RAM _dedicated_ to video, rather than inferior RAM
_allotted_ to
Video as in the ZX 81/ ZX Spectrum/ ZXBox etc.
As Pixels are only memory locations and the size
of the number they can hold is called Bitdepth.. As there are 8 Bits to one
byte, the cost per byte of this screen is 3 Bytes, so as there are 1024Bytes
to 1 Kilobyte the maths aare..
(((641*513)-1)*3)/1024 = 963.375K
As the PS2 has 4 MByte, it means that it has enough VRam for
(4*1024)/963.375 =
4 VRam buffers of this size with..
(4*1024)-(4*963.375) = 242.5K
left over. With 4:1 compression of a 640x480x24Bit screen, a VGA screen
would cost..
(640/4*480)*3/1024 = 225K
Which would be good enough for a compressed 4:1 Shenmue 2 or Halo.
Which would still leave 17.7K left over for sundries
Now as I can only look at 1 resolution/buffer of this size, at any one
time
there are 3 more buffers of this size + 242K laying around spare doing
nothing, can ANYONE explain to me why 4Megabyte isn't enough???
Thought not! Lol
Now the OBVIOUS question to ask, is why when the DC *supposedly* has 8MB of
RAM for video, is it actually using a tile based screen at ALL? Is this
more Sega HYPE or *PR marketing lies*?
A VGA /60Hz resolution would only use up
((640*480)*3)/1024 =900K,
and a machine with supposedly
8MByte of memory allotted for video, would have enough for 9 buffers of that
size, so give me ONE good reason, why you would hamfist the machine by
splitting a screen up into 300 little pieces IF the objective WASN'T to save
on video memory?
<Drums fingers>
I'm waiting. Mr Cleverdick!
> There are several advantages to this approach which are described in
> the white papers on www.powervr.com eg
> http://www.powervr.com/pdf/TBR3D.pdf
Oh, of course, I'm going to visit a powervr site for a balanced view of a
powervr product! [rolls eyes].. Tell you what, YOU go read that site and the
FIRST time they mention memory saving/ compression/ tiles/ whatever, you'll
know that it WON'T be outputting to a tv/monitors FULL capacity!
Ok then .. Now here's a DISADVANTAGE of using tile based screens.. And
rather than look at a silly little DC/XBox /GC etc, we'll look at the
overblown console that their graphics cards were based around.. ie a PC.
SCREEN8 : color,255,255: SET VIDEO 2,,,3: out&Hf6,14: For a= 1 to 50: COPY
SCREEN: NEXT <press return>
You can try this in an MSX 2 emulator on a PC, but you're never going to
find a PC *powerful* enough to ever be able to achieve it.
What it does is
to set an inbuilt Genlock for 2= superimpose [ie where transparent show live
video],,, 3= open up the left and right audio input channels for mixing with
internal [ie computer] sound. The for/next COPY screen loop then proceeds to
digitise 50 frames and the times I get for the for/next loop is 1.2 seconds,
which means that it's not only digitising @ 40+ fps, but actually imposing
and superimposing that video image over the live video it's digitising,
_with _ sound and or mixing. This is from any source, that you can plug into
a tv or directly via composite or SCART leads, so it's RGB too
Can you show me a single PC capture card which offers more than 25fps in PAL
or 30FPS in 60Hz? Even then you'll be told how many *MHz* your PC is
supposed to have, you'll have to buy ANOTHER graphics card for capture,
especially as my MSX 2 doesn't give a shit whether the input is analogue or
digital [ie _true_ multi-media]
I have a 256MB 2500+ Athlon with 128MB Geforce 4 and a cheapo webcam. With
webcam/PC combi, I can turn my head to the side, then back to the screen and
actually SEE myself looking to the side, then back to the screen and this is
at a very blurry/jerky framerate which I judge to be about 8-10 fps and this
is at a resolution of 160x120 which is less than my 8Bitter offers me. Know
what this tells me? The PC via Windows cannot handle real time digitising
and
why can't it? Because of low resolution tile based graphics, which are a
prerequisite of that bloated piece of software called Windows.
So where are all your M/GHz, M/G/Bytes, HD's, CDRom, powervr/GForces/ Ati's,
RDDDRM'FingSDDRAM's etc & etc now then? If you cannot frighten me with any
of this tech jargon/ shit what the fuck ARE you going to do? I've used BASIC
and I didn't even OPTIMISE that by declaring A as A% to make the computer
work in integer rather than floating point with up to 13 decimal places
[which is 1 more that Win 95 calculator offered! lol].. Apart from putting
Delay loops in to slow down the digitising, I think I'm being quite fair in
giving 3GHz PC's running in M/code a chance... Who's the Daddy? Lol
Now if you want to argue that the PC isn't getting it's arse kicked because
the MSX 2 [a 1985 spec btw], uses true bitmapped graphics, while the PC and
all it's minions use a crappy tile based system, then that's fine with me..
You'll just have to concede that a 3.5Mhz Z80A running in it's SLOWEST
language possible even for it, is better than a 2.5 GIGAHhz Athlon running
in M/Code and an old 1985 Yamaha 128K VDP (Video Display Processor ie
co-processor) is faster than a 128MB Geforce 4
Personally, even though I love my MSX 2's to bit[mapped]s , I don't believe
it's faster in
BASIC than any PC on the market today, so I have to put it down to crappy
tile based graphics and software which are holding it up.. But you're
welcome to try to convince me otherwise if you like, if you can come up with
a better explanation.
Before you do, I should explain that that both my MSX 2's ie My Philips 8280
http://faq.msxnet.org/hardware.html#Philips
And <ahem> Sony HBG900P
http://faq.msxnet.org/hardware.html#Sony
Are both upgraded internally to an MSX 2+ and while a 2+ is a faster
co-processor and can display a resolution of 512x424[interlaced] x 19000+
colours, now instead of digitising @ 40+ frames in real time from any
source, I'd be lucky to get 1 frame every couple of minutes in machine code,
from a VCR with a very good pause button.
The reason? To save on Video RAM [a 2+ uses exactly the same amount as MSX
2] the 2+ [which is a 19_88_ spec btw] uses a YJK tile based system, which
because of the FAKE resolution [ie non-bitmapped] has to have logical
operators acting on tiles to produce a fake pallette. As such, this makes
proceedings very slooooow as instead of letting the co-processor get on with
the task, the main processor has to
jump in to help it out with the logical maths! While the main processor runs
@ 3.5Mhz, the co processor runs @ 20+ MHz so this isn't a good idea is it?
I also noted that when the *powerful* graphics cards were being introduced
to the PC market [around Win 95/Direct X early days], processors which were
doing a fine job up until then, were
no longer *powerful* enough to run these *powerful* processors.
Now as a
co-processors job is to take the load OFF of the main processor, I did start
to wonder why instead of lightening the load, these *powerful* co-processors
were actually INCREASING it! My experience [which is only Beginners
level btw] with real computers like MSX,
put this down to the PC console via Windows using low resolution tile based
graphics and therefor the processor was having to jump in to help these
*powerful* co-processors out..
If you have another explanation,of why PC's are so shit in this area, I'm
willing to hear it!
But before you do, go here..
http://faq.msxnet.org/hardware.html#Sunrise
You'll see that I can upgrade my 8Bit to a 15Bit graphics card and via the
Video 9000 (a digitiser & genlocker) actually get real time digitising at
higher resolutions and
32,000+ colours WITHOUT upgrading my 3.5Mhz 8 Bit. The reason? Ya guessed
it.. The V9000 contains 4x the VRam of my MSX 2 and it uses TRUE BITMAPPED
graphics, so doesn't need the processor's involvement!
So you see, I don't bother with techy manuals, I use my eyes & brain. I've
never had any respect for a PC console and have never fallen for the hype
surrounding it. Knowing about tiles, logical maths operators, buffers/
memory usage isn't *high brow* stuff, it was BEGINNERS stuff when we had
REAL computers [ie pre- Amiga/ PC/ST consoles], as you learned about it if
you were at all interested in programming or simply the features a machine
offered. It was this kind of interest/curiosity which made me look at
Yabasic and anyone with an ounce of sense would know that it offers better
graphics than you're ever likely to see on a VGA/NTSC display. And therefor
XBox/ DC/ GC commercial games!
Sony is YET AGAIN ripping the PC market a new arse and this time it's with
the PS2 and the Eyetoy, a combination I'd never put my 3.5Mhz *powerhouse*
[lol] up against, even WITH it's 7Mhz switch on and using M/Code.
The Eyetoy mentions 1 resolution and that's 640x480 and I only need my eyes
to tell me it's 24Bit. At PAL's 25 fps, it means that the PS2 is getting
through..
25*900= 22,500 Kilo_Bytes_ per second
And the PS2 treats this as if it's nothing.. Think you could do THAT on a
tile based screen broken up into 300 little bits, while the camera will be
feeding in RGB values dot by dot in an 0-639 sequentially [ie the same as
memory is laid out] all the way up
to the 479th line??
CLUE: NOT a fucking hope in hell!
While 1/4 of this resolution chokes my PC, the PS2 still has the power to
add game graphics to each frame it digitises, then check the entire frame
for movement and collision between the *real* graphics and the game graphics
and not have one inkling of slowdown..
My Sony HBG900P's manuals contain the legend..
*Sony Corporation Printed in Japan (c) 1985*
So it really isn't surprising that when Sony were looking at the PS2, they
decided to spend billions on R&D, opening up factories, etc & etc, to
produce their own graphics chip, rather than pick up some off the shelf
shite that's used in the PC market and by _software_ manufacturers who
dabble in the hardware market eh?
> > Sorry if I've just pissed on your chips! :P
>
> Sounds like incontinence to me.
No incontinence is when it's *involuntary*, son, I did it on purpose, as
your over salty chips will now testify to! Lol
Incidentally, I notice you cut out the 2 other lines I wrote. EG..
*************************
VGA otoh, couldn't handle the output from Yabasic.. IE
OPEN WINDOW 640,512
**************************
Wonder why? Couldn't be that it cuts through the Hype that XBox/DC/ GC games
graphics can even compete with the resolutions that Sony gives BEGINNERS to
fart around with I s'pose?
S*O*N*Y!!! lol
If instead of rushing to the defence of a silly little DC, you'd loaded up
the FREE program supplied with the PS2, THEN used logic instead of
listening to HYPE from others, Yabasic could have saved you a load of
grief.. And me a lot of writing
Perhaps I'm not as wrong as I write eh? :P
James Sutherland
> A TV/monitor screen is essentially memory and it's true bitmapped.
> There is no earthly reason why a machine would actually use
> TILES to display to a screen, if NOT to save on memory.. Ergo, a DC
> /XBox/ GC doesn't use a VGA screen to it's full capacity. Got it?
The Xbox certainly has a full 640x480 frame buffer. It's a linear chunk of
RAM with every pixel addressable. It's not tiled. Same for the GC, as far
as I know, but I've never programmed that so I can't be sure.
The DC also has a full 640x480 frame buffer. The chip divides the
frambuffer up into 32x32 tiles for the purposes of rendering polygons,
which allows it to do certain optimisations in its sorting algorithms as
well as reducing memory bandwidth as rendering is done in register memory
on-chip before being copied out to the framebuffer. It deals with 32x32
pixels at a time when rendering, but it's not a tiled framebuffer in the
sense that you mean. It doesn't affect image quality or memory usage
(other than needing a bit of extra internal tile RAM on the chip).
Simon F
> "Simon F" <sim...@my-deja.com> wrote in message
> news:7f95c0fc.03091...@posting.google.com..
> > "Mark ellerman" <its...@tiscali.co.uk> wrote in message
> > > A DC is nowhere _NEAR_ VGA standard
> >
> > Sorry no. Apart from perhaps 1 or 2 early games that used 640x~240,
> > games use 640x480 on DC.
>
> Erm.. I wasn't talking about _vertical_ resolution!
It's still irrelevant. The DC supports a 640 pixel wide framebuffer.
(Actually it may be possible to drive it to higher resolutions. I
should check the programming guide)
> [Quote]
>
> -->*a DC etc would be outputting 640/4 x 480 for a 4x1 tile*<--
>
> I always gave the DC the benefit of the doubt vertically, otherwise I'd have
> uses 2x2 tiles so it would have been 640/2 x 480/2 for 4:1 compression.
>
> Good start.
NO. That is not what a "tile" means in PowerVR. I already pointed you
at the PowerVR white paper http://www.powervr.com/pdf/TBR3D.pdf . If
that's not enough I can give you PowerVR patent numbers (with my name
in them) and you can read those as well but I'm getting the impression
it would probably not help.
>
> > >as it uses a low resolution tile based
> > > system, to produce a fake/psuedo high resolution to fool the gullible!
> [much
> > > like the PC/XBox/GC etc].
> >
> > I'm sorry to say that you don't know what you are writing about.
>
> Well, that's a bummer, as I'll never get by on my looks.
Well I would never make it as a model either but at least I've got
almost 20 years of 3D computer graphics experience behind me.
>
> > > As a tile is designed to cover a larger area, a DC etc would be
> outputting
> > > 640/4 x 480 for a 4x1 tile which is a 1/4th of the true resolution that
> a
> > > VGA screen is capable of.
> > >
> > Absolutely not.
>
> *Absolutely not*, what? A tile by it's very NATURE is designed to cover a
> larger area, if you have a 12'x12' area, you don't go ordering 144x 2'x1'
> tiles, you order 72, likewise a 4'x1' tile = 36. The same thing with pixels,
> the bigger the tile, the less resolution ie places where you can put the
> tile! Simple logic!
NO. The tiles in PowerVR have a 1:1 relationship with framebuffer
pixels. There is no expansion.
>
> > A "tile" on PowerVR
>
> Lol! I'll repeat what I said earlier..
>
> **********************
> as it uses a low resolution tile based
> system, to produce a fake/psuedo high resolution to fool the gullible!
> [much like the PC/XBox/GC etc
> ************************
>
> Well, heeeello Mr Gullible! Lol
>
> >refers to a NxM pixel subsection of the
> > framebuffer
>
> But it's STILL a _tile_ Duh.. Do you REALLY _NOT_know the difference
> between true bitmapped and tile based?
Give me strength.
>
> A framebuffer is merely a lump of RAM btw. So can you explain why anyone
> would split RAM into smaller bits of RAM if the objective WASN'T to save on
> memory? Duh!
The RAM isn't split!!! The tiles refer to the order in which the frame
is rendered.
>
> >- IIRC, on DC the tiles are 32x32 pixels. A 640x480
> > display is thus subdivided into 20x15 tiles. Each tile is then
> > rendered completely before moving on to the next tile.
>
> BWAHAHAHAHAHAHA!!
>
> It's even WORSE than I thought! [If I believed you that is].
>
> ME: The DC etc is bad because it uses a tile based system.
>
> Mr Gullible: No it isn't you fool because it uses bigger tiles than you
> quoted!
Clearly I *am* gullible. I have been taken in by a troll.
>
> Go put your eye close to a TV or monitor son, you'll find that it's full of
> little dots called pixels and each of these pixels have R,G & B sections.
Struth. Actually it's more complicated than that. I suggest you read
chapter 3 of Andrew Glassner's "Principles of Digital Image
Synthesis". You'll see that pixels on a CRT are actually Gaussian
weighted sums of those R, G, and B dots.
The rest of this post I deleted because "Life is too short".
Simon F
Sir Chewbury Gubbins
<its...@tiscali.co.uk> writes
<snip>
Go on - tell the truth. There are no doors or windows in your house, are
there? :)
Choobs
--
Sir Chewbury Gubbins <chewbury...@nelefa.org>
Knight of the Wholly Gnarly Widget
http://www.nelefa.org
Mark ellerman
"James Sutherland" <ja...@guybrush.demon.co.uk> wrote in message
news:Xns93F9B567B32ADja...@212.159.13.2...
> "Mark ellerman" <its...@tiscali.co.uk> wrote in
> news:bk9mam$qd6e7$1...@ID-200061.news.uni-berlin.de:
>
> > A TV/monitor screen is essentially memory and it's true bitmapped.
> > There is no earthly reason why a machine would actually use
> > TILES to display to a screen, if NOT to save on memory.. Ergo, a DC
> > /XBox/ GC doesn't use a VGA screen to it's full capacity. Got it?
>
> The Xbox certainly has a full 640x480 frame buffer. It's a linear chunk
of
> RAM with every pixel addressable. It's not tiled. Same for the GC, as
far
> as I know, but I've never programmed that so I can't be sure.
Fine..
It uses a true bitmapped screens then..
NOW explain just why it is my
3.5Mhz 8 bitter, running in BASIC, can outperform my 2500+ Athlon in the
area of digitising/frame rates? You see once you take graphics [ie co
processor] out of
the equation all you're left with is the processor, which is akin to saying
a Spectrum can outperform a 2500+ Athlon from BASIC. That I find very
DIFFICULT to believe myself, but if YOU want to make the case...?!
I gave an example of when the *powerful* graphics cards started
appearing for the PC, main processors had to be upgraded, as a co processors
job is to take the load OFF the main processor, can you explain why instead
of decreasing the load they were INCREASING it?
Want another example?
Go play a DVD/ VCD /use an art package whatever on a PC in 24Bit.. Then
via Windows, reduce the bitdepth to 16Bit, then watch the DVD/VCD use the
art package again and I guarantee, you won't be able to see the difference
without really close scrutiny..
So how does THAT work out mathematically?
You've just reduced the possible pallette from (256*256*256=) 16,777,216 to
the equivalent of [ie spread over 3 values] (256*256=) 65536, which is a
loss of 16.7+ MILLION shades.. Now as a true bitmapped screen would exhaust
65536 colour pallette in a 256x256 display, care to explain what's going on?
Don't you feel that a loss of 16.7+ million colours, SHOULD actually
register visually in some way? Obviously there is some trickery going on
here.
I'm saying that PC's and all it's minions use tile based graphics to produce
a fake resolution & pallette, this seems to re-inforce my belief, so if I'm
wrong, explain to me how I can reduce a bitdepth to reduce the possible
onscreen pallette by 16.7+ million, yet not notice the difference?
IE instead of simply *telling* me I'm wrong, explain WHY I'm wrong!
> The DC also has a full 640x480 frame buffer. The chip divides the
> frambuffer up into 32x32 tiles for the purposes of rendering polygons,
So the DC cannot have polygons larger than 32x32 then? Pretty shitty machine
that eh? I showed an example of the PS2 via Yabasic, pumping out polygons
where 2 of the
coordinates were set to 0,0 to 640,512 which would start at memory start
address + memory location 0 and end at memory location (641*513-1)=
328,832..
On a DC it would start at m.s.a. + 0 to +(32*32=) 1024.. 1024?
Thats 1K, what the fuck sort of machine can only handle memory in 1 (8Bit),
2 (16Bit) or 3K (24bit) chunks?
Even a ZX Spectrum could handle more than that! Lol..
The Spectrum had high
resolution graphic statement from BASIC, where you could select a memory
register (ie 100,100) then draw a circle. The Spectrums limitation was that
as it used shared RAM [ala the ZXBox etc] it could only have 2 colours in an
8x8 matrix.. That circle may or may not actually pass through the first
32x32 pixels of the screen, so what the fuck use would it be to *render*
those? Or any of the other memory locations that the circle doesn't pass
through?
Say for example you want to draw a polygon from 19,27 to 73,15 to
118, 92 .. What are you supposed to do? Do a bit in one tile render it, do a
bit in another tile render it, then find out how many other tiles it has to
pass through then render bits of those to? Then got to the next poly, which
would be disecting the same tiles and do it all over again? That's going to
be an awfully fast way of getting a machine to output 1,000,000 polygons to
make up the entire screen eh?
What I was trying to explain is that it is the _rendering_ which produces
the resolution. If the DC was producing true bitmapped graphics then why
wouldn't they simply render a 640x480 COMPLETE buffer, rather than do it in
32x32 pieces of memory When the tiles are laid down, you're
still going to have to render the *joins* in that 640x480 buffer.
If you are using a true bitmapped screen, then you have set a chunk of
screen memory for an XXX x YYY set of viewing coordinates. You have also
allotted each memory address on the entire screen, a set amount of
bits/bytes the number of which will be displayed as a colour. So tell me,
once you've drawn a filled triangle, loaded each memory register with a
value /colour, what the hell IS there to *render*?
What you need to do on a true bitmapped screen, is to anti-alias all the
little jagged edges which have been cause by the fact you've used triangles
aka polygons, all of which have 3 sharp edges. These polygons can be as
small
as 3 pixels [ie 0,0 to 0,1 to 1,1] or as large as the entire diagonal buffer
coordinates [ie 0,0 to 0,640 to 640,512] so what earthly use is it to limit
this to 32x32 segments?
> which allows it to do certain optimisations in its sorting algorithms as
> well as reducing memory bandwidth as rendering is done in register memory
> on-chip before being copied out to the framebuffer.
Lol.. So HOW can you reduce memory _bandwidth_, without actually reducing
the _bitdepth_? It IS the bloody bandwidth you dope! Its the size of the
number that the memory address can hold!
If you've got 24 _Bit_ and reduce it to 16Bit, you are going to end up with
LESS than you did with 24Bit, 24 bits would mean that a memory register can
hold a number up to 24 bits or 3Bytes long, 16 bit means that it can hold a
number 16 bits long or 2 bytes long.. See the difference? 8 Bits or 1 byte
per pixel/memory register _less_!
Look at what you're saying for goodness sake, your saying that you can take
1 from 3 and still have 3 left! You must be a wow with loaves & fishes!
A _true_ bitmapped screen cannot be compressed without consequences as it's
WYSIWYG, it's your
allotted *canvas*.. You don't see artists sticking up a canvas, then
painting on little tiles of canvas to stick to that canvas do you? Neither
would anyone use graph paper with a certain resolution, then split that up
into tiles and complete every tile before moving on.
When you are copying 300x 32x32 tiles, to a screen, there are only actually
300 places you can put these tiles.. You cannot put them @ 431, 22 nor can
you put them @ 213,143, so you aren't working in a TRUE BITMAPPED enviroment
right? Just what is so HARD to understand about that?
Incidentally, you cannot simply change resolution/bitdepth *midflight*, when
you change from 24-16Bit you'll notice that there is a perceptible *blank*
period as memory resets itself to a lower *bandwidth*/bitdepth. Try it via
Windows.
This is the same with normal RAM. When from BASIC you defined a variable[s]
as single precision [DEF SNG [Variable]], you could no longer do double
precision maths. The computer would then *render* RAM accordingly, which
would save on memory and speed things up. As video ram is designed for
_display_ any changes that you make to memory registers, will produce a
*blank* bit as memory resets itself to your bidding! This isn't rocket
science, memory is just a storage area.
As I explained GTRIANGLE in YABASIC, gives a graduated fill, based upon 3
colours that the user selects for each of it's sides, so the PS2 is doing
it's *algorithms* _directly_ to it's 641x513 memory buffer, in a triangular
[ie polygon] shape, where any of the entire 641x513 coordinates (ie this
points to a SINGLE memory register] are available for the triangles
coordinates. If there is anything wrong with the triangle, then it's the
programmers fault as s/he input the coordinates and also the colour values
for the 3 sides.. And if that's the problem, there will be no gain in
letting a computer *render* it, unless of course it can bloody mind-read!
>It deals with 32x32
> pixels at a time when rendering, but it's not a tiled framebuffer in the
> sense that you mean. It doesn't affect image quality or memory usage
> (other than needing a bit of extra internal tile RAM on the chip).
Oh I see, it _reduces_ memory bandwidth, but doesn't affect _image quality_
or _memory usage_? Great, I'll reduce my old 8 Bit to 2 Bit and it'll still
be able to do 16Bit precision maths! Lol.. Tell me *if* there is _no_
difference, WHY reduce it in the first place? Duh
You do know that to reduce something, you make it less? If you reduced a
Spectrum to 4Bit, then it could no longer do 8 Bit maths, without trickery.
ie doubling up on it's 4Bit memory registers. It would HAVE to be 4Bit
registers as the 4Bit Spectrum wouldn't be able to address any more! This
would increase a 16K Spectrum's (16*1024=) 16,384 accessible memory
locations to 32,768, but you'd still only have 16K of RAM!
This was my whole POINT btw. RAM = RANDOM ACCESS MEMORY.. So if you have
640x480 memory locations and you cannot RANDOMLY ACCESS those MEMORY
locations, then you DON'T have 640x480 RANDOMLY ACCESSABLE MEMORY locations
now do you?
And why do you need *tile RAM* exactly? This is how I explained how the old
8 Bitters worked, you have a tile based screen with tile shapes being stored
elsewhere, which could be *rendered* into any shape you like, then fed back
to the screen. Never heard of user definable graphics characters? You could
stick 32x 8x8 characters across the screen, then access each individual
pixel within those 8x8 characters to give a 256x8 resolution. Problem came
when you tried to move those characters as you had to do it 8 pixels at a
time. The other problem is that you had to address the tiles using an 8Bit
number, rather than addressing each pixel/memory location individually.
Incidentally, I DID explain how tiles worked in the previous post, it was
the other poster who brought in the 32x32 tile bit in, to which I had a
little bit of a laugh at him. In my previous post I
stated that memory registers were containing tiles of 4x1 and actually gave
the maths based on this. I can assure you that if I'd believed that the DC
used 32x32 tiles as YOU seem to think that *I* think they are, you'd have
been getting a lot less than my quoted 225K per screen, as there wouldhave
only been 300 memory locations, instead of my stated 76,800! I even stated
that the 32x32 mode was actually 8x 4x1[tiles] x 32, so I never deviated
once from
my original stance.
I did however accredit the DC tiles with 24Bit, while
the Powervr site seems to boast of 16bpp so I may have overestimated on my
225K per 640x480 screen/buffer. This however is irrelevant as it still
doesn't alter the fact that a DC doesn't use anything like a VGA screens
true potential!
Now if you'll simply admit I'm right we can move on. :P
Mark ellerman
> "Mark ellerman" <its...@tiscali.co.uk> wrote in message
news:<bk9mam$qd6e7$1...@ID-200061.news.uni-berlin.de>...
>
> > "Simon F" <sim...@my-deja.com> wrote in message
> > news:7f95c0fc.03091...@posting.google.com..
>
> > > "Mark ellerman" <its...@tiscali.co.uk> wrote in message
> > > > A DC is nowhere _NEAR_ VGA standard
> > >
> > > Sorry no. Apart from perhaps 1 or 2 early games that used 640x~240,
> > > games use 640x480 on DC.
> >
> > Erm.. I wasn't talking about _vertical_ resolution!
>
> It's still irrelevant.
Memory is simply a sequential set of addresses, resolution is simply these
set of memory locations set out in a XXX x YYY set of coordinates. A tile as
I explained will be spanning 4x1 tv pixels, but only actually using 160
memory locations.. This is TOTALLY relevant, otherwise the memory locations
which are on the lower line, would be moving up to the upper line as they're
merely sequential memory locations. Once that starts happening the YYY
coordinates get reduced, which is why vertical resolution is important.
Get it now?
I explained that when I said that I was using a 4x1 tile, rather than a 2x2
tile formation.. Do try to keep up!
>The DC supports a 640 pixel wide framebuffer.
> (Actually it may be possible to drive it to higher resolutions. I
> should check the programming guide)
You have to check? I already gave the maths to show that a DC [supposedly]
has enough Vram for 9 x 640x480x 24Bit resolution buffers.. If the [reputed]
8MB allotted to Vram is correct, then I'd say that it's a given that it
would offer better then a 640x display. The fact that it doesn't access a
true 640x480 buffer, but has to access via 32x32 tiles is what this
*discussion* is all about essentially!
My old 8 Bitter can theoretically [*] display 1024x424 in 2Bit [ie 4 colour]
using 106K of it's 128K Vram.
[*] I say theoretically, as no tv not even PAL [which is 17-18% higher
resolution than NTSC/60Hz], doesn't offer those kinds of resolutions, so I
haven't been able to check.
My 8Bitter can interlace screens either in a odd/even _line_ formation, or
in a
0 2
1 3
Vram page formation, where it is a sequential set of memory addresses, where
end address of page 0, leads to the start of page 1 and the end of page 1
leads to start address of page 2 etc.
While each pixel is addressable individually [ie it's a bitmapped screen],
this is NOT a normal resolution as you cannot access 0-1023 in a sequential
way, so as this is a type of _tiled_ resolution, the memory is _fragmented_.
On a normal 512x resolution, all the graphics statments like LINE/CIRCLE /
PAINT/ DRAW / PSET, PRESET etc, deal with coordinates to pinpoint memory
registers.. So once you have drawn your picture/graphics [ie loaded the
memory locations with digital values], what IS
there to *render*? And why the hell would you fragment memory into 32x32
little pieces, to do this rendering, when the memory is right there
_literally_ staring you in the face?
> > [Quote]
> >
> > -->*a DC etc would be outputting 640/4 x 480 for a 4x1 tile*<--
> >
> > I always gave the DC the benefit of the doubt vertically, otherwise I'd
have
> > uses 2x2 tiles so it would have been 640/2 x 480/2 for 4:1 compression.
> >
> > Good start.
>
> NO. That is not what a "tile" means in PowerVR. I already pointed you
> at the PowerVR white paper http://www.powervr.com/pdf/TBR3D.pdf . If
> that's not enough I can give you PowerVR patent numbers (with my name
> in them) and you can read those as well but I'm getting the impression
> it would probably not help.
'Ere you calling me fick again, Mr Gullible?
Well, I pointed you back to this site and advised that YOU should read it
and stated that * the
FIRST time they mention memory saving/ compression/ tiles/ whatever, you'll
know that it WON'T be outputting to a tv/monitors FULL capacity!*. Here's a
quote from you beloved powerVR site/paper.
************************
In fact, PowerVR's quality of rendering at 16bpp is the equal or better of
many systems quality at 32bpp.
*******************************
Seems like it's YOU who has a little trouble with understanding literature
eh?
The site was BOASTING of the powerVR's ability to use memory
compression/saving and actually recommended it for machines which use UMA
[shared RAM for graphics ala the, ZX 81, ZX Spectrum, ZXBox etc], which is
inferior to true VRam for obvious reasons.
Now the real question is what are you doing putting your name on
papers etc., when you CLEARLY haven't a clue about the product you're
writing about! :P
What I've been trying to explain to you is, is that it's the *rendering*
which is producing the fake resolution and pallette. Hardware manufacturers
have long since knuckled down under the Microsoft yoke and are making the
hardware to suit the software. This is NOT a very good idea.
> > > >as it uses a low resolution tile based
> > > > system, to produce a fake/psuedo high resolution to fool the
gullible!
> > [much
> > > > like the PC/XBox/GC etc].
> > >
> > > I'm sorry to say that you don't know what you are writing about.
> >
> > Well, that's a bummer, as I'll never get by on my looks.
>
> Well I would never make it as a model either but at least I've got
> almost 20 years of 3D computer graphics experience behind me.
Well, that's nice dear, but what does that have to do with anything? A TV
display is 2D and memory is sequential so it's 2D also when displayed on a
TV. As a 3D programmer, surely even YOU know that you merely give the
PERSPECTIVE of 3D on a 2D device, so it really has no bearing on the subject
of memory does it?
When holo-suite's become the norm, perhaps you'll be able to brow beat me
with your *lineage*, until then, no chance!.
> > > > As a tile is designed to cover a larger area, a DC etc would be
> > outputting
> > > > 640/4 x 480 for a 4x1 tile which is a 1/4th of the true resolution
that
> > a
> > > > VGA screen is capable of.
> > > >
> > > Absolutely not.
> >
> > *Absolutely not*, what? A tile by it's very NATURE is designed to cover
a
> > larger area, if you have a 12'x12' area, you don't go ordering 144x
2'x1'
> > tiles, you order 72, likewise a 4'x1' tile = 36. The same thing with
pixels,
> > the bigger the tile, the less resolution ie places where you can put the
> > tile! Simple logic!
>
> NO. The tiles in PowerVR have a 1:1 relationship with framebuffer
> pixels. There is no expansion.
So what you're saying essentially is the DC/Powervr can only have 65,536
colour pallettes on a screen eh? After all that PVR site states 16bit per
pixel, so if you're going 1 for 1 then 16Bit is all you're going to get!
Jeez you're dumb. If you were only going 1:1 then what earthly reason would
you pass memory through FRAGMENTED memory [ie a tile] only to get exactly
the SAME result at the other side?
If you have a true bitmapped screen, which only display a value which you
load into memory, then what the hell IS there to *render*? And PLEASE don't
tell me polygons again, a polygon is not a square.. A polygon doesn't have
to have a 0,0 - 31,31 limit.. and a polygon doesn't have to be restricted to
20x15 little areas where they have to be confined to. At least not on a
true bitmapped screen they don't.
> > > A "tile" on PowerVR
> >
> > Lol! I'll repeat what I said earlier..
> >
> > **********************
> > as it uses a low resolution tile based
> > system, to produce a fake/psuedo high resolution to fool the gullible!
> > [much like the PC/XBox/GC etc
> > ************************
> >
> > Well, heeeello Mr Gullible! Lol
> >
> > >refers to a NxM pixel subsection of the
> > > framebuffer
> >
> > But it's STILL a _tile_ Duh.. Do you REALLY _NOT_know the difference
> > between true bitmapped and tile based?
>
> Give me strength.
Well, it was a valid question and the answer appears to be *NOT*!
With a 16K machine, when loading from tape/disk/cart/ whatever, the load
would be being done in one go, in a 16K chunk. The program would then access
any of that 16K chunk as it sees fit. If a tape/disk was starting/ stopping
during it's loading, the most obvious thing that would be happening is that
it's uncompressing/ compressing as it goes. The mere fact that the DC is
using tiles when transfering from one storage area to another, shows that
compression/uncompression has been happening along the way.
> >
> > A framebuffer is merely a lump of RAM btw. So can you explain why anyone
> > would split RAM into smaller bits of RAM if the objective WASN'T to save
on
> > memory? Duh!
>
> The RAM isn't split!!!
Of course it's split, it's split into tiles YOU told me that! lol
Even on the 8 Bitter type tile based screens, you could lay 32x 8x8 tiles
and *render* that 256x8 resolution in any way you liked, that doesn't mean
that this was RANDOMLY ACCESSABLE Memory, it wasn't as the mere FACT that
you'd used TILES meant that you'd forfeited the right to RANDOM Access!
A _TRUE_ bitmapped screen is uncompromising. Each pixel/memory location will
have it's OWN RGB value, or will be capable of storing a value as large as
the *mode* permits. 8bit =1Byte will be the *cost* per pixel, 16bit =
2bytes, 24Bit = 3bytes and so on.
True Bitmapped = WYSIWYG as it is pure visual in your face memory. The PS2
can appear *grainy* it can also appear *jaggy* and this is down to using a
superior graphics system rather than an inferior one. It can also look
gorgous as in many games, or in the Eyetoy menu screen where anyones living
room will be displayed according to time of day, weather outside, seasonal
changes/ whatever.
Even in the Eyetoy's MENU screen, the PS2 is ripping the PC market a new
arse, this is because it is dealing with TRUE bitmapped graphics on a TRUE
640x480 resolution, so it doesn't have to go *rendering* little fragmented
bits here and there, to produce the fake resolution/pallette.
>The tiles refer to the order in which the frame
> is rendered.
[sigh].. But the frame IS a buffer, which will have a memory start address
and a memory end address, so when you load a value into memory, there is
nothing TO actually *render*. If you load a bit/ byte of data into a memory
location, just what actually needs tarting up? And if you have 640x480
memory locations, what earthly USE is it to split that into 32x32 tiles to
tart up, when you're going to then have to tart up the the areas where the
tiles *join*?
I actually told you HOW the DC worked and how
the tiles worked, as it is the actual *rendering* which is producing the
resolution and extra colour pallette. I credited the DC/powerVR with 24Bit
colour, you are crediting it with 16bit, even a fucking blind man could see
that I'm closer than you are!
16Bit is the equivalent [ie spread over 3x RGB values] of (256*256)=65536
colour pallette.. On a TRUE BITMAPPED screen, this pallette would exhaust
itself in a 256x256 resolution.
Yabasic offers 24Bit colour which is (256*256*256=) 16,777,216 colour
pallette. Using a 640x480 resolution, it would take..
16777216/(640*480-1) =
54.61 x 640x480 resolutions before IT actually exhausted itself.
A 256x256 resolution against 54x 640x480 resolutions???? Quite a bit of a
discrepancy eh? So which pallette are YOU going to claim for the DC?
Much as it will CHOKE DC fans, they are going to HAVE to agree with me when
I give the DC a colour pallette in the millions rather than a measly 65+
thousand.
Even the PowerVR site only claims 16bpp, so how does the DC get that 8Bits
of data back?? I already EXPLAINED that, when I said that the 32x32 tiles
are made up of 8x 4x1tiles x 32 and that it is the rendering which is
producing the fake pallette awa as the fake resolution. You see it's the
*8x* which actually gets those lost 8Bits of data BACK and allows the
pallette to be increased again
The problem with this method is that you have to cover 32x tv pixels to get
the full range for the fake resolution. A true bitmapped screen can get the
range using 1 single pixel/memory location.
I did actually credit the DC with 24Bit tiles, so may have erred on the side
of caution where my 225K per fake 640x480 was overgenerous, that aside, it
doesn't detract from my original statement that the DC doesn't use VGA to
it's FULL potential. Even if we were talking about TRUE bitmapped screens, I
would also have been correct as a 16Bit 640x 480 display would use 600K as
opposed to a 900K which I gave the maths for for a 24Bit true bitmapped
display.
> > >- IIRC, on DC the tiles are 32x32 pixels. A 640x480
> > > display is thus subdivided into 20x15 tiles. Each tile is then
> > > rendered completely before moving on to the next tile.
> >
> > BWAHAHAHAHAHAHA!!
> >
> > It's even WORSE than I thought! [If I believed you that is].
> >
> > ME: The DC etc is bad because it uses a tile based system.
> >
> > Mr Gullible: No it isn't you fool because it uses bigger tiles than you
> > quoted!
>
> Clearly I *am* gullible. I have been taken in by a troll.
ROTFLMAO, let's see, I give you examples of an 3.5Mhz 8Bitter kicking a PC's
arse
in the area of digitising/ interactive desk top video /multimedia.. You
don't refute it. I even give you an example BASIC program so that you can
test in an emu that at least the commands/ statements are there even if
you'll never find a PC *powerful* enough to actually DO the job.
I give an example of the PS2 doing the same with the Eyetoy.
I give you facts, figures, basic listings [ie Yabasic], all of which are
easily checkable and therefor easily refutable, yet you refute not a SINGLE
one.. You merely snip the lot & come back pouting and spouting the same
DRIVEL which made me respond to you in the first place.
And *I'M* the troll?
> > Go put your eye close to a TV or monitor son, you'll find that it's full
of
> > little dots called pixels and each of these pixels have R,G & B
sections.
>
> Struth. Actually it's more complicated than that. I suggest you read
> chapter 3 of Andrew Glassner's "Principles of Digital Image
> Synthesis". You'll see that pixels on a CRT are actually Gaussian
> weighted sums of those R, G, and B dots.
Isn't that what I said? A collection of dot with RGB values per dot! I
didn't need a book to find that out, many many years ago, I sneezed while
drinking a glass of water, the upshot being that the water landed on the
screen, thereby *magnifying* the pixels and I sort of got the idea from
there!
You've completely missed the point again btw. I don't care how the pixels
get to the tv screen/monitor, that's the tv's job. My point was that they're
there to be used and the RGB values are there to be used, NOT using them to
their full their full potential is NOT using a VGA monitors resolution to
IT'S full potential.
> The rest of this post I deleted because "Life is too short".
Lol.. Couldn't refute any of it more like!
Pride, as they say, comes before the fall. If you had read the post, and
understood it, you would have known that there was so much ammunition there,
that only a fool would try to reply against my arguments.
You see, I didn't bother with a powerful PS2 to take on a DC in my example,
but went lower [ie my 3.5Mhz 8Bitter] and used it to attack a much higher
specced PC on which the DC's graphics cards are based. I even used _BASIC_
which is the slowest language that my 8Bitter can run in and STILL gave an
example of it digitising @ 40+ fps, which is higher than any specialised PC
card will offer.
Now on what PLANET does a 3.5Mhz Z80 compete with a 3GHz Pentium/Athlon in
ANY area? Perhaps if the Z80 were running in M/Code and the Pentium/Athlon
in BASIC then there just MAY be a few cases, but to reverse this and still
think that it ISN'T the graphics process which is causing the slowdown, is
complete lunacy! Especially when I already gave an example of MSX 2+
screens, which also use tile based graphics to produce a fake
resolution/pallette, which would slow down the SAME 8Bit machine from 40+fps
digitising in Basic, to 1 frame every few _minutes_ using MACHINE CODE!
Mark ellerman
"Sir Chewbury Gubbins" <chewbury...@nelefa.org> wrote in message
news:sNL+SSI48Xa$Ew...@dowcarter1.freeserve.co.uk...
> In message <bk9mam$qd6e7$1...@ID-200061.news.uni-berlin.de>, Mark ellerman
> <its...@tiscali.co.uk> writes
> <snip>
>
> Go on - tell the truth. There are no doors or windows in your house, are
> there? :)
Which is why I have to use a worprocessor, as I'm not allowed anything sharp
in here!
Seriously though, I've stated that Yabasic offers a better resolution than
XBox /DC/ GC games, and given an example of how and why. Easy to check/
refute eh? . Nobody has refuted
it. Don't you find that strange when popular concensus put's XBox/ GC and
sometimes DC graphics ABOVE the PS2? So who's talking bollocks?
I gave the maths to show that the PS2 has enough VRam for 4x screens of
Yabasic quality, then taunted all those *4MB isn't enough* merchants to
actually explain WHY 4MB isn't enough.. Nobody has answered.. So who's
talking bollocks?
I've stated that Yabasic offers graphics up to and over twice as good as any
format they've watched Toy Story 2 on.. So where ARE all these people who
are going to warn _me_ not to fall for the *Sony hype*? Or refute my claim?
So who's talking bollocks?
I can remember reading in this group, where everyone was slagging off the
PS2's graphics and when someone mentioned that VRam was merely a buffer, was
being told that this was simply *Sony lies* and *PR marketing shit*. I
stated that even though Yabasic is higher resolution than DC/Xbox/ GC games,
it is only a buffer as the PS2 has enough for 4x this amount with 200+K left
over.. So where are all these people telling ME that I'm falling for the
*Sony hype*/ *PR marketing lies*? So who's talking bollocks?
I've given examples and listing which can be checked, of how/ why my 18 year
old 3.5Mhz 8 Bit is outperforming my [recently] brand new 256MB 2500+ Athlon
& 128 MB Geforce 4, from _BASIC_.. Nobody is refuting it! A 3.5 MHZ Z80A can
kick the arse of a 2500+ Athlon??? Running in fucking BASIC? If you take
graphics out of the equation, THAT'S what it boils down to! Kinda kicks
Moore's Law for touch eh? So who's talking bollocks?
I've also stated that the PS2 is also ripping the PC market a new arse in
the digitising market [ie the Eyetoy], which is a visual up to date example
that anyone can check.. Nobody is refuting it! Which means that the XBox 2
which will no doubt be designed around existing PC technology, WON'T be able
to compete with the PS2 in this area let alone the PS3.. So who's talking
bollocks?
I'm saying that the PC and all it's minions problem is that it uses tile
based graphics as opposed to true bitmapped graphics.. Some ARE refuting
it.. Fair enough, I can admit that I'm wrong.. I did however ask that *if* I
am wrong, someone explain to me why a 3.5MHz Z80A
running in BASIC the slowest language that it can run in is kicking a PC's
arse. Nobody is giving an explanation [or at least none that make any
sense]! So who's talking bollocks?
See the problem here? They are right and they don't have to give a reason as
to why they are right and simply ignore any factual evidence to the
contrary! IE the evidence of their own eyes! This is the classic *Napoleon
complex* so the lunatics are running the asylum! Therefor I am in here for
my own safety to keep the loonies out! :)