SGL replacement

[RockinB]

EDIT 2006-03-01: screenshots updated(see also this post), new functions:

slSpriteCCalcNum, slSpriteCCalcCond, slSpriteColMode, slSpriteType, sl1MapRA, sl1MapRB, slPageRbg0, slCharRbg0, sl16MapRA, sl16MapRB

slBitMapRbg0, slInitBitMap, slBitMapBase, slBMPalette

slLocateBitMap, slClearBitMap, slBMPset, slBMPoint, slBMBox, slBMBoxFill, slBMGet, slBMPut, slBMSprPut

EDIT 2006-03-21: new functions:

slBMCircle, slBMLine, slPrintMatrix, slLocateNbg (slLocateNbg0, slLocateNbg1, slLocateNbg2, slLocateNbg3)

slLocatePage, slExtSignal, slScrTransparent, slBackColTable, slLineColTable, slLine1ColSet

slLineColDisp, slColorCalc, slColorCalcOn, slColOffsetOn, slColOffsetOff, slColOffsetAUse, slColOffsetBUse, slColOffsetA, slColOffsetB

Hi everyone,

I've been working on a SGL replacement recently. I started with Charles MacDonalds examples which don't use any SEGA library, used portions of it in wrappers and re-implemented a subset of SGL functions.

sl16MapRA, sl16MapRB, sl1MapRA, sl1MapRB, slBack1ColSet, slBackColTable, slBitMapBase, slBitMapNbg0, slBitMapNbg1, slBitMapRbg0, slBMBox, slBMBoxFill, slBMCircle, slBMGet, slBMLine, slBMPalette, slBMPoint, slBMPset, slBMPut, slBMSprPut, slCharNbg0, slCharNbg1, slCharNbg2, slCharNbg3, slCharRbg0, slClearBitMap, slColorCalc, slColorCalcOn, slColOffsetA, slColOffsetB, slColOffsetAUse, slColOffsetBUse, slColOffsetOff, slColOffsetOn, slColRAMMode, slDispHex, slDispSprite, slDMACopy, slExtSignal, slGetHCount, slGetVCount, slInitBitMap, slInitSystem, slLine1ColSet, slLineColDisp, slLineColTable, slLocate, slLocateBitMap, slLocateNbg (slLocateNbg0, slLocateNbg1, slLocateNbg2, slLocateNbg3), slLocatePage, slMapNbg0, slMapNbg1, slMapNbg2, slMapNbg3, slPageNbg0, slPageNbg1, slPageNbg2, slPageNbg3, slPageRbg0, slPlaneNbg0, slPlaneNbg1, slPlaneNbg2, slPlaneNbg3, slPlaneRA, slPlaneRB, slPrint, slPrintFX, slPrintHex, slPrintMatrix, slPriority, slSpriteCCalcCond, slSpriteCCalcNum, slSpriteColMode, slSpriteType, slSynch, slTVOff, slTVOn, slVRAMMode, slScrAutoDisp, slScrCycleSet, slScrDisp, slScrPosNbg0, slScrPosNbg1, slScrPosNbg2, slScrPosNbg3, slScrTransparent, slZoomMode, slZoomNbg0, slZoomNbg1

It does already work with a few simple SGL games. But there's much work ahead (debugging).

I hope to be able to use it in some of my Saturn homebrew and to take advantage from the possibilities involved in the fact that the source code is available.

Website: www.rockin-b.de/saturn-sglrep.html

Please let me know what you think! And considering the fact that I'm not an expert in programing without SEGA libs, I'd welcome anyone who would like to help implementing or debugging. Actually, I expect nothing less.

Some screenshots to compare:

(with SGL) (with SGL replacement)

 

[slinga]

From your site: "It is created in the intention to allow certain Saturn homebrew applications to work just as if they were using the original SGL."

Amazing stuff, but why bother? The SGL is a pain to work with, poorly documented, some stuff just don't work, etc. This is a hard project you've undertaken and I think you'd be better served writing your own library that does things it's own ways then trying to perserve compatibility with existing Saturn homebrew applications. It's not like there's not that many homebrews out there (probably less than 20).

 

[RockinB]

Originally posted by slinga+Sun, 2006-02-26 @ 04:28 PM--><div class='quotetop'>QUOTE(slinga @ Sun, 2006-02-26 @ 04:28 PM)</div><div class='quotemain'>From your site: "It is created in the intention to allow certain Saturn homebrew applications to work just as if they were using the original SGL."

Amazing stuff, but why bother? The SGL is a pain to work with, poorly documented, some stuff just don't work, etc.

[post=144714]Quoted post[/post]​

[/b]

I disagree, the SGL has been very useful for me. Documentation can be improved by translating newer japanese docs.

Originally posted by slinga@Sun, 2006-02-26 @ 04:28 PM

This is a hard project you've undertaken

[post=144714]Quoted post[/post]​

Actually I don't intent this project getting hard, as I don't want to recode the entire SGL, only most common used functions. And as far as available, I'd like to use existing code.

<!--QuoteBegin-slinga@Sun, 2006-02-26 @ 04:28 PM

and I think you'd be better served writing your own library that does things it's own ways then trying to perserve compatibility with existing Saturn homebrew applications.

[post=144714]Quoted post[/post]​

[/quote]

This project is not necessarily about creating an own lib. Suppose there is a nice homebrew lib of the kind that your talking about, then I just take it and use it to fake the SGL functions.

On a side note: I don't want to offend, but somehow I can see in the way that you argue that you are a linux fan. It's not everything bad what other people have done. I still have to see the guy putting together a library that can take it up with SGL.

 

[ExCyber]

Hmm... this should be enough to rebuild arflash... as far as I remember I only used slSynch, slPrint, and slPrintHex.

 

[Zaksund]

This looks great so far! And here's to hoping its smooth sailing for the most part! Man, I have so got to get Yabause running...

Amazing stuff, but why bother? The SGL is a pain to work with, poorly documented, some stuff just don't work, etc.

I dunno...I never thought of the SGL as being that much of a pain, just kinda bloated. I look at half the functions listed in ST-238-R1-051795 and think to myself "when the hell would I actually ever use that!?". While it is a bit of a chore, I'm guessin' most folks can figure out how something works between the manuals and the examples.

But it's good to see that Rockin' is just focusing on common commands. The more options coders have the better, and keeping it simple is a definite plus.

 

[slinga]

Did you ever get color text working by any chance? If your sgl replacement can get it to work I'll use it :thumbs-up:

 

[RockinB]

Great progress: lot's of bugs removed, slPrint stuff is now faster, smaller, uses exactly the same hardware resources like the original, more demos work, aaaaaaand: bitmap library implemented!!!

Originally posted by ExCyber+Sun, 2006-02-26 @ 07:40 PM--><div class='quotetop'>QUOTE(ExCyber @ Sun, 2006-02-26 @ 07:40 PM)</div><div class='quotemain'>Hmm... this should be enough to rebuild arflash... as far as I remember I only used slSynch, slPrint, and slPrintHex.

[post=144720]Quoted post[/post]​

[/b]

I haven't tried, but I'm sure it'll work.

<!--QuoteBegin-slinga@Wed, 2006-03-01 @ 09:27 PM

Did you ever get color text working by any chance? If your sgl replacement can get it to work I'll use it :thumbs-up:

[post=144810]Quoted post[/post]​

[/quote]

You can either use a:

* small(compressed), 1 color font

* custom font with 256 colors

* bitmap font from Charles MacDonald (not recommended)

(My fonts for option 1 and 2 only have a subset, not 256 chars as most are bullshit and waste memory. However, I added a special character for slingas games , see the screenshots. I don't know if I should support full fonts with compile flags?)

So yes, colored fonts are possible. But changing the color at runtime is not implemented, currently. Changing the font palette is possible by the user.

Sad, but your snake is the only game that crashes, I think it has something to do with snprintf(), but I have got no clue why snprintf should crash the app? Maybe Antime would know...

 

[mrkotfw]

This is great! Amazing work! Maybe everyone can be weaned off the real libraries! Would you actually replace a few tedious functions from the original SGL/SBL or try to keep it as 1:1 as possible? I'd like to see some ideas from SBL to be integrated into SGL. Maybe this is a start for the very first real homebrewn library!

 

[RockinB]

Thanks Piratero!

Originally posted by Piratero+Fri, 2006-03-03 @ 12:09 AM--><div class='quotetop'>QUOTE(Piratero @ Fri, 2006-03-03 @ 12:09 AM)</div><div class='quotemain'>Would you actually replace a few tedious functions from the original SGL/SBL or try to keep it as 1:1 as possible?

[post=144832]Quoted post[/post]​

[/b]

About the most sophisticated SGL features like real time gouraud, depth cueing and so on, I don't know if they'll ever come. The rather easy stuff comes first and I already implemented a lot of functions that I don't use in my homebrew.

When it can be done better like possibly in the bitmap functions I'm currently working on, then I might add some compile flags to activate the improvements, as long as they need more cpu power, more space or if the original SGL behaviour could be of any use. Otherwise I could make the improvements default.

Originally posted by Piratero@Fri, 2006-03-03 @ 12:09 AM

I'd like to see some ideas from SBL to be integrated into SGL.

[post=144832]Quoted post[/post]​

Which one, please tell me.

<!--QuoteBegin-Piratero@Fri, 2006-03-03 @ 12:09 AM

Maybe this is a start for the very first real homebrewn library!

[post=144832]Quoted post[/post]​

[/quote]

Anybody got controler handling code which does not use SH2 direct mode? I extenden that of Charles to support the 2nd port, too, but in the end I think it's too slow.

 

[mrkotfw]

The way SBL handles it's sprites is pretty nice.

 

[CyberWarriorX]

Anybody got controler handling code which does not use SH2 direct mode? I extenden that of Charles to support the 2nd port, too, but in the end I think it's too slow.

I wrote some the other week, the only thing is, the code isn't entirely working correctly(it doesn't seem to collect data consistently), and I'm not sure why.

 

[RockinB]

Originally posted by CyberWarriorX@Sun, 2006-03-05 @ 03:34 PM

I wrote some the other week, the only thing is, the code isn't entirely working correctly(it doesn't seem to collect data consistently), and I'm not sure why.

[post=144875]Quoted post[/post]​

Cool! It would be great if you could share the code for use in the SGL replacement project (e-mail to C4_2005@rockin-b.de). Maybe the problem can be figured out when working with the code and the docs.

Thanks, CWX! :banana

BTW: for what project did you write the code?

 

[RockinB]

Over the past weeks, I added new functions (see first post).

The bitmap library is now complete, you can even draw lines and circles(the speedy way, of course )!

The VDP2 functions (which I'm focusing on) are getting near completion, except for rotating stuff.

Finally, I could improve slScrAutoDisp() to compute correct cycle patterns(test bench on PC), but some improvements can still be done. I still (since I made my own slPrint) have no display on real Saturn, although I have on emulators.

Anybody knows what exactly is involved in a resolution switch from 320 -> 352, for rexample? I mean those res.changes which imply a CPU speed increase of 10 percent.

Originally posted by CyberWarriorX@Sun, 2006-03-05 @ 03:34 PM

I wrote some the other week, the only thing is, the code isn't entirely working correctly(it doesn't seem to collect data consistently), and I'm not sure why.

[post=144875]Quoted post[/post]​

Hey CWX, I've tried to contact you about 3 times the last 2 weeks. Now as I'm curious, I saw you've been active just yesterday. If you don't want to share, just tell me (rather than ignoring my requests), that's no problem.

About your problem: I guess you already know that sometimes, not all data can be aquired since the output buffer is too small, so the collection must be told to continue manually by the SH2.

 

[RockinB]

I got now display on real Saturn, I just had called only slScrDisp instead of slScrAutoDisp inside slInitSystem.

Strange thing: all characters seem to be shifted right somehow, only on real hardware on emu it's correct. Don't know why, if I could only dump the VDP2 registers with an emu to compare the settings...

 

[mrkotfw]

Upload a binary, i'd like to see. Also, how exactly are you calculating the bits? I mean, adding up the bits.

 

[RockinB]

Originally posted by Piratero@Wed, 2006-03-22 @ 08:55 AM

Upload a binary, i'd like to see. Also, how exactly are you calculating the bits? I mean, adding up the bits.

[post=145218]Quoted post[/post]​

Don't know what bit's you mean? As for VDP2 registers, I have a local register buffer which enables write only registers to be read. As for the bits, sometimes it's been difficult to find out which address bits to take. I also don't prevent writing bits in registers, which are marked as ignored.

Here is Slinga's 12 Player Pong, SGL and SGLrep version, both as binary and iso.

[attachmentid=1799]

Note: compiled wihout optimizations, font to be improved, hehe.

Compare how it looks in yabause and on real Saturn. There is some sense hidden in the difference, but I don't get it.

 

[mrkotfw]

Mind showing me the code for your "local" buffer? I'll test soon, I have to go to work in a few hours

 

[RockinB]

Originally posted by Piratero@Wed, 2006-03-22 @ 08:45 PM

Mind showing me the code for your "local" buffer? I'll test soon, I have to go to work in a few hours

[post=145225]Quoted post[/post]​

PM sent.

 

[RockinB]

No feedback? If all those motherfucking emulators wouldn't keep crashing on every system I got, I could do the VDP2 register dump/comparison myself, but so I'm stuck waiting until yabause supports register dumping.

 

[RockinB]

@devvers:

From your experience, what are the disadvantages/flaws/lacks of the SGL?