I've commited some code tonight for accessing the dma controller. Its pretty much the same thing as my tutorial doc, with some minor tweaks. I'll be adding loser's additions in the near future which includes chains, scratchpad support and interrupt-safe routines. Or he can add it himself, if he's feeling spicy...
I've also added a basic graphical library and a sample on how to use it. It is nothing fancy beyond setting a video mode, setting display/draw/z buffers, gif packet building functions and some vram upload/download functions that have yet to be completed. Its not meant for blazing speed, but its enough to learn the basics of PS2 graphics but without the extras to get in the way or hold your hand.
Enjoy!
Dma and graph additions.
-
Oobles
- Site Admin
- Posts: 347
- Joined: Sat Jan 17, 2004 9:49 am
- Location: Melbourne, Australia
- Contact:
Where does this leave the gsKit and dmaKit work? It seems to me that we need to have some kind of plan for what should be added in this area on ps2sdk. So first a few questions..
DMA
How similar or different is dmaKit to the dma code you've done? It it work merging dmaKit, Loser's code and your code together? Any advantage or have different approaches been taken?
GS
I mentioned on IRC that the name graph is very generic. Originally I thought it would be good to have a directory which covered the GS. Then have other projects build on the basic functionality it provided. At one time I thought gsKit would be that. However, it seems that gsKit has already out grown that specification.
Also, what about libraries to access other related components like VIF or what ever else is there. Its been too long since I've even looked at this area. Are these part of the same library, or separate?
I'm glad we're getting these additions to the sdk, I'd just like to know that the additions are well thought out and hopefully provide the basic building blocks to make it easier to build higher level libraries.
Oobles.
DMA
How similar or different is dmaKit to the dma code you've done? It it work merging dmaKit, Loser's code and your code together? Any advantage or have different approaches been taken?
GS
I mentioned on IRC that the name graph is very generic. Originally I thought it would be good to have a directory which covered the GS. Then have other projects build on the basic functionality it provided. At one time I thought gsKit would be that. However, it seems that gsKit has already out grown that specification.
Also, what about libraries to access other related components like VIF or what ever else is there. Its been too long since I've even looked at this area. Are these part of the same library, or separate?
I'm glad we're getting these additions to the sdk, I'd just like to know that the additions are well thought out and hopefully provide the basic building blocks to make it easier to build higher level libraries.
Oobles.
I haven't really looked at dmaKit much at all, so I don't know where that would stand. Loser's additions are a fairly simple thing to add and with them there isn't much else a dma library would be asked to do, really...
As for the graph library, its a generic name because its a generic interface to the graphical parts of the PS2. It really only handles GS setup and GIF packet building/sending for the most part. You could think of it as a GS and GIF library in one. Hence, 'graph'. :)
The main reasons I added these are because I offered to (when ps2sdk was first being formed), and the ps2sdk readme mentions the upcoming addition of a basic graphic library, which this is. I also figured gsKit would be a little too comprehensive for most peoples' tastes and something basic was needed to be there to avoid situations like the port of SDL relying on gsKit when all it really needed was a basic blit-to-screen library.
And really, it wasn't like anyone was actually getting around to it... :)
As for the graph library, its a generic name because its a generic interface to the graphical parts of the PS2. It really only handles GS setup and GIF packet building/sending for the most part. You could think of it as a GS and GIF library in one. Hence, 'graph'. :)
The main reasons I added these are because I offered to (when ps2sdk was first being formed), and the ps2sdk readme mentions the upcoming addition of a basic graphic library, which this is. I also figured gsKit would be a little too comprehensive for most peoples' tastes and something basic was needed to be there to avoid situations like the port of SDL relying on gsKit when all it really needed was a basic blit-to-screen library.
And really, it wasn't like anyone was actually getting around to it... :)
I like this kind of initiative, I mean to provide basic frameworks for those who like to tackle the hardware in their manner... I think libs, like GsKit for example, are dedicated to another kind of people who doesn't really want/need/like to go in depth in the PS2 architecture (especially for ps2 ports for example).
They give an higher level of abstractino to the programmer who wants it.
On my side, I prefer to build my dma tags by myself and do not let a lib doing it for me... but that's demo programming, performance is needed...
In the same way, I'd like a day to see the VULib from Saotome included in ps2sdk and a subset of gfxpipe to handle dmac pipes.
Still in the same topic, I'm writing a EE Timer lib which offers 3 levels of abstraction :
- the lower one, to handle directly the EE Timers registers
- a middle one which helps you to manage timers without setting any register
- a higher one, for lazy people, who simply need some kind of features like Delay, GetElpasedTime, GetFPS,... without even knowing there are timers behind....
But that's another story :D
So, that's only MY opinion, but thanks you ooPo :D
They give an higher level of abstractino to the programmer who wants it.
On my side, I prefer to build my dma tags by myself and do not let a lib doing it for me... but that's demo programming, performance is needed...
In the same way, I'd like a day to see the VULib from Saotome included in ps2sdk and a subset of gfxpipe to handle dmac pipes.
Still in the same topic, I'm writing a EE Timer lib which offers 3 levels of abstraction :
- the lower one, to handle directly the EE Timers registers
- a middle one which helps you to manage timers without setting any register
- a higher one, for lazy people, who simply need some kind of features like Delay, GetElpasedTime, GetFPS,... without even knowing there are timers behind....
But that's another story :D
So, that's only MY opinion, but thanks you ooPo :D
- TiTAN Art Division -
http://www.titandemo.org
http://www.titandemo.org
You'll find a link to it in this thread:ooPo wrote:What's this vulib you talk about?
http://forums.ps2dev.org/viewtopic.php?t=1142