-
Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.
DOOM on 7 MHz m68000
- Thread starter johnklos
- Start date
I dont know what the A500 uses for graphics processing, whether its accelerated or not.
but 68000 Macs have no acceleration, and everything is done entirely on the CPU.
but 68000 Macs have no acceleration, and everything is done entirely on the CPU.
Here's a video about previous DOOM clones for the Amiga. Note that it doesn't really make a clear distinction between games that run okay on the original 68000s verses needing later Amigas.
The short version is that Amigas *do* have substantial video acceleration capabilities compared to the completely dumb video of a Mac, but given it's mostly optimized towards tasks like playfield scrolling and sprite placement it's questionable how much it really helps drawing texture-mapped 3D shapes.
The short version is that Amigas *do* have substantial video acceleration capabilities compared to the completely dumb video of a Mac, but given it's mostly optimized towards tasks like playfield scrolling and sprite placement it's questionable how much it really helps drawing texture-mapped 3D shapes.
The Amiga woudl almost have to be using graphics acceleration
I spent the last several months writing routines and drawing graphics on bare metal 68K systems, although it does work ok, its still kinda slow. and thats even with the GCC optimizer cranked all the way up and integer-only math.
it would take hyper-optimized routines especially using the 68k move.m instruction multiple registers into video memory to get any kind of speed. GCC wont do this.
I spent the last several months writing routines and drawing graphics on bare metal 68K systems, although it does work ok, its still kinda slow. and thats even with the GCC optimizer cranked all the way up and integer-only math.
it would take hyper-optimized routines especially using the 68k move.m instruction multiple registers into video memory to get any kind of speed. GCC wont do this.
Last edited by a moderator:
I am curious what he's doing. If I had to take a wild guess based on the odd chunky dithering of the texture maps... I dunno, I wonder if he's doing something with the blitter that effectively amounts to rendering the scene at effectively a much lower resolution and using the blitter to "splat" the dither-blobs (which the CPU manipulates as if they were a single pixel) into the full resolution frame buffer. Remember how the original DOOM let you shrink it down to a little postage-stamp size resolution to run on a too-slow computer? Basically he's doing that but the blitter is working as a magnifying glass?
Last edited by a moderator:
Yea, I dont know.
I never studied computer graphics much so all the fancy features of newer or more advanced hardware is beyond my current knowledge scope.
Only thing I have ever done, was draw directly into framebuffer memory.
In case your curious what I was talking about, its this:
Thats an un-accelerated 68010 system that I wrote a new program for. (Original was downloaded over satellite and is long since gone with the death of analog subcarrier)
I even had to write a mini stack/task switching kernel so I could run parallel graphics operations without one stalling another.
I never studied computer graphics much so all the fancy features of newer or more advanced hardware is beyond my current knowledge scope.
Only thing I have ever done, was draw directly into framebuffer memory.
In case your curious what I was talking about, its this:
Thats an un-accelerated 68010 system that I wrote a new program for. (Original was downloaded over satellite and is long since gone with the death of analog subcarrier)
I even had to write a mini stack/task switching kernel so I could run parallel graphics operations without one stalling another.
Last edited by a moderator:
Similar threads
