#PIXEL PLOTTING
7 messages in this thread
Please help me as I am trying to plot single pixels on an AMIGA screen VERY
quickly. I want to do this in asm using DEV Pac 3 on an A1200 with 50MHz 68030,
6 Mb RAM. I also could use HiSoft Pascal and link in an asm object file. I am
new to 68000 programming, but am fimilar with asm principles as I have coded
advanced grahpical programming on PEECEE's for a while.
Can any one get me out of PC hell and let me enter the Brave new World OF the
AMIGA!!
Leigh –
Keep in mind that the Amiga's chip RAM (where the screens are) is MUCH slower
than its fast RAM due to DMA contention. So if you really want speed, you
might be better off using your fast CPU to plot your pixels to a buffer in fast
RAM and then moving the area into chip RAM en masse; it all depends on what
you're doing.
If you're doing scaling and stuff for a Doom-style game, you might consider
doing the above with chunky (PC-style) graphics and then using a fast
chunky-to-planar convertor. Several are here in the library; just search using
the keyword "chunky." I must warn you, though, that I've only gotten two to
work on my A4000/040 (the '020-only one and the '040-only one). (Of course,
I'm not exactly what people call a "guru" either. 😉 I got about 30 frames per
second on a 256-color low-res screen with the '040 one.
There are also some library routines (like WritePixel()), but they're *REALLY*
slow compared to the above method or even just poking the bitplanes directly
with the CPU.
– Jim, on AutoPilot!
>Keep in mind that the Amiga's chip RAM (where the screens are) is MUCH
>slower than its fast RAM due to DMA contention. So if you really want
>speed, you might be better off using your fast CPU to plot your pixels to
>a buffer in fast RAM and then moving the area into chip RAM en masse; it
>all depends on what you're doing.
>There are also some library routines (like WritePixel()), but they're
>*REALLY* slow compared to the above method or even just poking the
>bitplanes directly with the CPU.
I'm working on a DOOM sytle engine myself, I'ld be REALLY interested
in how this is done. The code you mentioned doesn't help me much since
it is written for a 020+ processor, and I'm trying to develope an
engine to work on ALL amiga processors (like the 68000) and I don't
know which intstructions are for the faster chips. I'm not that familar
with 680×0 asm code, but I'm learning.
I've also tried to find out how to "poke" screen memory directly.
If you have code examples or can enlighten us on this, please do!
Thanks,
Gary
>> I'm working on a DOOM sytle engine myself, I'ld be REALLY interested
>> in how this is done.
I can send you what I've done; it's just a very simple scaler, though. If you
swap out the chunky-to-planar routine I used, it should run on a 68000 machine.
Oh, almost forgot — I used an 8-bitplane screen. It shouldn't be hard to
modify the program to use 5 planes, though.
>> The code you mentioned doesn't help me much since it is written for a
>> 020+ processor, and I'm trying to develope an engine to work on ALL
>> amiga processors (like the 68000) and I don't know which intstructions
>> are for the faster chips.
Well, I tried to write my own chunky-to-planar, but I only got 8fps out of it
on my 040. It was all in-line code, too. :l Obviously not optimized, though.
Since the 68000 is so much slower than the 68040, the chunky-to-planar might
not be the best way to do the program in this case.
>> I'm not that familar with 680×0 asm code, but I'm learning.
I'm not either, and I am too. 🙂 It's not hard once you get the hang of it.
>> I've also tried to find out how to "poke" screen memory directly.
>> If you have code examples or can enlighten us on this, please do!
Okay, but I'll need a little time to go review my program and cull the
necessary parts for the discussion.
– Jim, on AP!
>I can send you what I've done; it's just a very simple scaler, though. If
>you swap out the chunky-to-planar routine I used, it should run on a 68000
>machine.
I'll look forward to seeing it.
>Since the 68000 is so much slower than the 68040, the chunky-to-planar
>might not be the best way to do the program in this case.
I think that you may be right here. What I was thinking about is why do
I need a chunky to planar converter in the first place? If I'm using
bitmaps that were created in a native Amiga display mode and converted
ahead of time to RAW image data, it seems to methat all I should ever
need to do would be to rotate and scale the texture maps.
Now if I plan on allowing the game to read user created GIF files,
etc, then I'm converting PC based images to the Amiga display and such a
routine would ne needed. I'm lost on the whole chunky to planar thing.
Why would I need such a routine?
As you can well imagine, this has turned into quite a complex project.
It's definatley been a learning experience.
Gary
>> I think that you may be right here. What I was thinking about is why do
>> I need a chunky to planar converter in the first place? If I'm using
>> bitmaps that were created in a native Amiga display mode and converted
>> ahead of time to RAW image data, it seems to methat all I should ever
>> need to do would be to rotate and scale the texture maps.
IF you can figure out a speedy way of scaling the planar data. Don't forget
that getting or writing one planar pixel requires multiple reads or writes,
plus some other logical operations to maintain the integrity of the other
pixels or to isolate the pixel you're working on. That's one reason the PC's
have such an advantage doing texture-mapped graphics: they use chunky pixels,
which are much better suited for that type of graphics manipulation.
>> Now if I plan on allowing the game to read user created GIF files, etc,
>> then I'm converting PC based images to the Amiga display and such a
>> routine would ne needed. I'm lost on the whole chunky to planar thing.
>> Why would I need such a routine?
The chunky-to-planar (c2p) routines are there so that you can rotate the chunky
images with the main CPU (assuming it's fast enough) and then display them on
the screen (which uses planar graphics on the Amiga).
I had thought of doing the scaling and rotation with the CPU, converting the
chunky wall/baddie/whatever to planar, then letting the blitter stamp it on the
screen for me instead of worrying about software blitting like PC's have to.
Of course, I don't know how to do most of that anyway. <g>
>> As you can well imagine, this has turned into quite a complex project.
>> It's definatley been a learning experience.
That can be said of all projects. 😉 Almost nothing is as simple as it seems
at first glance. (Just ask me about polygons. <g>)
– Jim, on AP!
The texture mapping algorithm that I have seen works by stepping through
screen pixel positions and calculating which pixel in the bitmap should be
plotted there. If you tried doing this directly from Amiga bitmaps you
would either have transfer one bit from each bitplane for each pixel or do
the whole texture map seperatly for each bitplane.
I am working on an idea for a program that does simple "Wolfenstein" style
displays using chunky pixel bitmaps for its input but writing the output
directly to Amiga bitplanes. I got the idea from reading the source code
for ACK which is available in the Games Development forum. This does all
its texture mapping in vertical strips, so I intend to setup pointers to
all of the bitplanes and setup bitmasks to set and clear the current bit
positions in two data registers. It should then be a simple case of doing
the texture map calculation and shifting each result once for each
bitplane, either clearing of setting the plane depending on whether a 1 or
a 0 falls off the end. So far I have not actually written any code so I
don't know if this will run at a useable speed. I will be developing on a
33MHz 68030 with ECS, and probably also a 14MHz 68020 with AGA.
Peter Wade
Autopiloting from London, England