Amiga.org
Operating System Specific Discussions => Amiga OS => Amiga OS -- Development => Topic started by: SoLo2 on December 18, 2005, 05:28:52 AM
-
Hello!
I am new to the Amiga World! :D
Testing a little assembler I
got to this code, that sets the
screen I will be using.
So, it seems like it _must_ be
reinitialized at each screen refresh,
true?
That means that it can be initialized
in the copper list, or otherwise in a
separate routine,
that writes directly to the registers.
The problem arises when changing
the "diwstrt" and "diwstop" registers.
If I try using horizontal (x) start and
end coordinates that are more to the
left, for example $xx51 and $xx91,
(this would start,stop at 079,145+256)
then the effective visible line shrinks
from 320 down to 272. The virtual line
seems to remain the correct 320, but
you see I set the modulo registers
($0108, $010a) to zero, to not have a
bigger, virtual line...
Why? who knows?
CopperList
dc.w $0100,$1200 ;bplcon0 set 1 plane, color
dc.w $0108,$0000 ;bpl1mod offset to next line
dc.w $010a,$0000 ;bpl2mod offset to next line
dc.w $008e,$3081 ;diwstrt start coords 048,129
dc.w $0090,$30c1 ;diwstop stop coords 304,449
; 320 (normal) visible line width
dc.w $0092,$0038 ;ddfstrt L margin normal (horz)
dc.w $0094,$00d0 ;ddfstop R margin normal (horz)
; to point to bitplane 1
dc.w $00e0 ;bitplane0 hi
hi0
dc.w $0000
dc.w $00e2 ;bitplane1 lo
lo0
dc.w $0000
dc.w $0182,$0ff0 ;color01
I am using excellent UAE-0.8.21
emulator under Linux. Great!
SoLo2
-
SoLo2 wrote:
Hello!
I am new to the Amiga World! :D
Testing a little assembler I
got to this code, that sets the
screen I will be using.
So, it seems like it _must_ be
reinitialized at each screen refresh,
true?
That means that it can be initialized
in the copper list, or otherwise in a
separate routine,
that writes directly to the registers.
Welcome to amiga.org!
Of course the hw registers don't _have_ to be reinitialised at each refresh - you can set them just once and they will stay that way until you change them.
It's just handy to have them in the copperlist.
The problem arises when changing
the "diwstrt" and "diwstop" registers.
If I try using horizontal (x) start and
end coordinates that are more to the
left, for example $xx51 and $xx91,
(this would start,stop at 079,145+256)
then the effective visible line shrinks
from 320 down to 272. The virtual line
seems to remain the correct 320, but
you see I set the modulo registers
($0108, $010a) to zero, to not have a
bigger, virtual line...
Why? who knows?
CopperList
dc.w $0100,$1200 ;bplcon0 set 1 plane, color
dc.w $0108,$0000 ;bpl1mod offset to next line
dc.w $010a,$0000 ;bpl2mod offset to next line
dc.w $008e,$3081 ;diwstrt start coords 048,129
dc.w $0090,$30c1 ;diwstop stop coords 304,449
; 320 (normal) visible line width
dc.w $0092,$0038 ;ddfstrt L margin normal (horz)
dc.w $0094,$00d0 ;ddfstop R margin normal (horz)
; to point to bitplane 1
dc.w $00e0 ;bitplane0 hi
hi0
dc.w $0000
dc.w $00e2 ;bitplane1 lo
lo0
dc.w $0000
dc.w $0182,$0ff0 ;color01
I am using excellent UAE-0.8.21
emulator under Linux. Great!
SoLo2
I really have no clue. Why are you messing with diwstrt and diwstop anyway? I never understood them and didn't really try to - just found values that worked and used those same values for ever - dc.w $8e,$2c81,$90,$2cc1 - centred for every (Pal) TV or monitor I tried.
Just thinking about this makes me remember how much fun Amiga coding used to be. I suddenly want to buy another A1200 and write a parallax starfield with a sine-scroller and glenz-vectors.
I never had anywhere near so much fun coding on XBox, GC, PS2, or DC. (PS1 was cool to code on also.)
-
Lando wrote:
(PS1 was cool to code on also.)
It was such a shame Sony dropped the Net Yaroze, there was some cool stuff produced with it. I remember one really unique game involving a time traveling snail.
-
Lando wrote:
I never had anywhere near so much fun coding on XBox, GC, PS2, or DC. (PS1 was cool to code on also.)
You used to code for consoles? Professionally or homebrew?
-
Hello!
Interesting is, to be able to have a
virtual line length of at least double
length the physical line length:
physical=320, virtual=640 (lo-res);
physical=640, virtual=1280 (hi-res)
This is the best for horizontal scrolling.
The physical screen (or line length) is
the part of a very large screen (the virtual)
shown to the player.
Consequently, the virtual screen is "like"
an extension of the physical, that makes it
much larger.
In fact only double as large.
The virtual is more like an super screen
that "contains" the visible screen.
The physical part acts like a window that
moves over the total screen width.
It is incremented pixel by pixel, and then
Word by Word (16 pixels), by de/incrementing
registers $DFF102 BPLCON1 and $DFF0E0 to
$DFF0F6 BPL?PTH/L, until a whole physical
screen width has been scrolled.
At this point the physical window position
jumps back to the beginning, by resetting
the screen base addresses BPL?PTH/L.
In this example we increment by 2 pixels,
to make the drawing shorter:
================== frames
|physical########| 0,1
==================
|#physical#######| 2,3
==================
|##physical######| 4,5
==================
|###physical#####| 6,7
==================
|####physical####| 8,9
==================
|#####physical###| a,b
==================
|######physical##| c,d
==================
|#######physical#| e,f
==================
|########physical| 0,1
==================
flip both window parts
and we are at the start:
==================
|physical########| 0,1
==================
Always after scrolling 1 whole Word, the
program has to fill 1 Word column at the
new border of the screen, and 1 Word column
in the just disappeared border of the screen.
This column painted at the disappeared border
is a column of a whole screen "to come"
(in the future of the scrolling).
This is an "amortized" way to cope with the
big jump, when the physical is resetted to
the beginning of the virtual screen.
This way we avoid a frame that takes longer
to paint, because it has to refill the whole
window with "tiles".
The question is:
Is it possible to have such a big virtual
screen with Amiga's hardware?
SoLo2
-
I doubt there was much on the Net Yaroze that the CD32/SX32 couldn't manage.
We neglect our hidden heritage!
-
Hyperspeed wrote:
I doubt there was much on the Net Yaroze that the CD32/SX32 couldn't manage.
We neglect our hidden heritage!
The PlayStation 1 was way more powerful even than a CD32/SX32 Combo. The CD32 lacked 3D hardware (Akiko doesn't really count). Something like Ridge Racer Type 4 or Resident Evil 3 still couldn't be done to the PS1 standard on a 060 equipped A4000 without at least a 3D card. The minimum spec for the conversion of Wipeout 2097 (the only PS1 conversion I know of for the Amiga) was a PowerPC accellerator and 3D graphics card and even then the framerate wasn't as high as the PS1.
I never actually used a Yaroze when I first started PS1 programming - I started on a standard chipped grey PS1 connected to a PC via an Action replay cartridge and a parallel cable.
lou_dias wrote:
Lando wrote:
I never had anywhere near so much fun coding on XBox, GC, PS2, or DC. (PS1 was cool to code on also.)
You used to code for consoles? Professionally or homebrew?
First homebrew, then professionally over 5 years. I worked on about 6 published games for the major consoles. Homebrew is more fun - there is so much pressure when you're working to deadlines and a 7-days a week, 16 hours a day schedule when you're nearing the end of a project or coming up to a big show like E3 where you have to show a demo. But still nothing beats walking into a game store and seeing the end result on the shelf.
-
I know all that...
The CD32 came out in 1993 and the Playstation 1 was 1996. Even for those 3 years the PS1 was proportionally way more powerful.
However, if you put an SX32 into the CD32 and play a few Amiga scene demos then you won't see anything on the Yaroze home brewed that could match the quality of the 3D in the Amiga demos.
I have been calling on other threads for a cheap PPC/3D GPU to be made for the classic Amigas but for some reason hardware developers are too geeked up with crappy mediator-style pass-thru boards for defunct PCI cards and the USB stuff.
I wish someone would give us some meaty gaming hardware. The Phase5 PPC boards were not slender enough to be cheap and gamer friendly, they fussed about too much with SCSI, SIMM slots etc.
As for programming homebrew, I hear there are cults that program for the Dreamcast (and it's Visual Memory card) and the Atari Jaguar!
:-)