This place is dead!

[Omni]

Ah, well...I have attempted a bit of Saturn coding. I am quite sure I could pull off the basics...I don't have much knowledge regarding the math needed for a full 3D game, like regarding collision, and I barely understand the texture coordinate demo that Rockin-B made, though it looks awesome and I do have something of a grasp on it...as to how he did it, though...I am at 25% comprehension.

As for me, I've kinda got other things to do besides Saturn programming...not to say that it isn't interesting...I'm taking a look at Rockin-B's tutorial as we speak, and the idea of using Daemon Tools + emulator to test games sounds intriguing, but...there's a barrier in terms of motivation and drive I haven't passed yet. In particular I'm already working on a simpler PC game with some friends, and though I like programming, I need to finish what I'm on, not experiment more at the moment...

If I had a modchip I would definitely try the texel demo. As it looks like an awesome piece of work.

EDIT: just so you know, Rockin-B, your tutorial also looks excellent and in fact, so simple that I believe I will indeed try it sometime.

 

[RockinB]

If we could lower the amount of new things to learn for developers new to Saturn dev... . All their previously gained knowlegde of APIs and stuff is useless for devvers when they come to Saturn. No common used file formats, no widespread dev libs, ... .

Just everytime I think about porting a game it pushes me back when I remind me that it's a lot easier when I port it to GP32 or Dreamcast.

So what about:

- a MOD player (Morden asked me about that)

- an OpenGL subset compatible wrapper which uses SGL or SBL's SPR and MTH libs

- a port of SDL which uses hardware acceleration using VDP1 and VDP2

- libraries for image reading, compression, maybe 3D fileformats

What do you think?

 

[Omni]

I thought I remember someone telling me that SDL wouldn't work on Saturn because of the huge difference in the way the Saturn treats video memory?

But, there's always workarounds, I guess. Those sound like cool ideas.

 

[Mask of Destiny]

Unless there's some feature of the Saturn hardware I'm unaware of (which is certainly possible), SDL would be hard to port (at least the video portion anyway) in an accelerated fashion. SDL is really oriented around blitter-type 2D acceleration which I don't believe the Saturn has. Might be possible to simulate it using VDP1 sprites, but I don't know if it's flexible enough. I suppose you could implement it in software on the slave SH-2 if you had to. It's not like the GP32 has accelerated video.

 

[RockinB]

Originally posted by Rockin'-B@Wed, 2005-08-17 @ 03:04 PM

So what about:

- a MOD player (Morden asked me about that)

- an OpenGL subset compatible wrapper which uses SGL or SBL's SPR and MTH libs

- a port of SDL which uses hardware acceleration using VDP1 and VDP2

- libraries for image reading, compression, maybe 3D fileformats

What do you think?

[post=138373]Quoted post[/post]​

So who is going to do it? :wanker

 

[RockinB]

Originally posted by Rockin'-B@Fri, 2005-08-19 @ 12:09 PM

So who is going to do it? :wanker

[post=138440]Quoted post[/post]​

Sorry, I forgot that I'm always talking to myself when it comes to that.

I guess I found the ultimate reason why the Saturn homebrew community went down.

Think back in 2003, the SX Saturn Coding Compo was running, quite a lot of people (compared to now) were active and even I got convinced to make something, too.

The biggest mistake was to make a poll to decide the ranking of the entries, which is what no other Compo is doing. I'm saying this in regard to the homebrew community, which got shocked by the low response of the Saturn gamers. Only few participated in the poll. And from that day on, the community activity died rapidly.

So it's the lack of interest in our efforts by the Saturn gaming comunity which showed up in the voting. I think noone expected that.

There is no vital homebrew if noone cares about it.

 

[vbt]

Originally posted by Rockin'-B@Wed, 2005-08-17 @ 05:04 PM

- a MOD player (Morden asked me about that)

I'm sure it can be done.

- an OpenGL subset compatible wrapper which uses SGL or SBL's SPR and MTH libs

I've not check this yet.

- a port of SDL which uses hardware acceleration using VDP1 and VDP2

I took the source of the SDL and tested a tutorial but there a lot of functions to port and so maybe I wrote only one. The first step would be to port it without hardware acceleration.

It would be great to have a sdl lib because there are a lot of games to port.

- libraries for image reading, compression, maybe 3D fileformats

[post=138373]Quoted post[/post]​

A pîcture readear with jpg support would be nice but I'm still wondering how to put and isplay a 1280*1024 picture on a saturn.

I will add add a "game to port" page on the saturn dev section, I have some sources that I grabbed and wanted to move to saturn. It goes from simple game like othello to rise of the triad

It's not yet written, I'll try to do that this week. Then I should stop to update SX sections and return to Saturn dev.

 

[vbt]

Originally posted by Rockin'-B@Wed, 2005-08-24 @ 12:40 PM

The biggest mistake was to make a poll to decide the ranking of the entries, which is what no other Compo is doing. I'm saying this in regard to the homebrew community, which got shocked by the low response of the Saturn gamers. Only few participated in the poll. And from that day on, the community activity died rapidly.

even me hope to see more vote as there are many people registered on SX and also many people looking for games. It's hard to keep motivated when nobody cares about. I'm still motivated to finish the sms emu for instance but I'm stucked with cz80 with works on smsplus/sdl and not on smsplus saturn.

 

[RockinB]

About SDL:

Yes, hardware acceleration is the last thing. What I'm unsure about is the SDL thread stuff. Don't know if this feature is widely used and I don't know if SH2 allowes threads.

I want to add another item to the list:

A memory allocation library which uses high work RAM, low work RAM, cartridge RAM, if present. All without to make the program care about where the stuff is placed to.

Is it possible to replace malloc? Some additional functions which incorporate priority to optionally have controll, because the RAMs feature different speeds.

Originally posted by vbt@Wed, 2005-08-24 @ 11:23 AM

even me hope to see more vote as there are many people registered on SX and also many people looking for games. It's hard to keep motivated when nobody cares about. I'm still motivated to finish the sms emu for instance but I'm stucked with cz80 with works on smsplus/sdl and not on smsplus saturn.

[post=138663]Quoted post[/post]​

As for your SMS emu: I'm your biggest fan :banana !

Yes, porting emus to Saturn is something special, because of the endianess and unaligned accesses. Only few emus have been running on a similar CPU, so the authors often didn't care about that and sometimes they only guessed and could not verify (GNUBoy).

So you already could change the cpu core in the PC version?

BTW: there is another Z80 core announced written in sh4 asm. FameZ80 or something, from the same author who made the sh4 68k emu.

 

[RockinB]

Originally posted by vbt@Wed, 2005-08-24 @ 11:14 AM

A pîcture readear with jpg support would be nice but I'm still wondering how to put and isplay a 1280*1024 picture on a saturn.

I will add add a "game to port" page on the saturn dev section, I have some sources that I grabbed and wanted to move to saturn. It goes from simple game like othello to rise of the triad

[post=138662]Quoted post[/post]​

Maybe with palette and using the map/cell approach? Or resizing it in software for display on a NBG0 bitmap scroll.

I've just looked at rise of the triad, but I decided that Aleph One would be much better, since the whole Marathon Trilogy is released as free!

 

[Mask of Destiny]

Originally posted by Rockin'-B@Wed, 2005-08-24 @ 01:04 PM

About SDL:

Yes, hardware acceleration is the last thing. What I'm unsure about is the SDL thread stuff. Don't know if this feature is widely used and I don't know if SH2 allowes threads.

Multi-threading (or at least proper pre-emptive multi-threading anyway) just requires a relatively high frequency interrupt source (usually a timer) to give control back to the OS to do a context switch.

I want to add another item to the list:

A memory allocation library which uses high work RAM, low work RAM, cartridge RAM, if present. All without to make the program care about where the stuff is placed to.

Is it possible to replace malloc? Some additional functions which incorporate priority to optionally have controll, because the RAMs feature different speeds.

I have an inprogress memory allocator that tries to handle RAM of different capabilities (including VRAM and the like). It's for a game oriented operating system I was thinking about writing. My initial target was the Sega CD, but I'm tempted to start with the Saturn first.

 

[Zaksund]

Think back in 2003, the SX Saturn Coding Compo was running, quite a lot of people (compared to now) were active and even I got convinced to make something, too...

Amen bro. I remember when I first stumbled onto this site...I was in awe. At first I was gonna try dev for DC, but just learning that it was possible to program for sega's underrated little black box made my choice.

Then the community just died! I dunno what happened, but a few posts everyday, dropped to maybe 3 a week if we're lucky. At first I was like "well everyone must be keeping their projects quiet till they're totally done." but after a few months it was clear that there were only a few actually programming stuff.

Hey Rockin'! I took your advice and am now rewriting to support bin files. This was the best thing I could've done for my source!!...its just taking forever to re-code everything.

I'd like to see libs for 3D file format handling. Right now we've gotta convert the same model sooo many times in order for it to be Saturn usable. For example, I use anim8or for 3D (its free & requires no install...that's right, you can run it on your work computer ). So to get a model for Saturn I've gotta:

1. export my file as .3ds

2. convert it to dxf using crossroads converter.

3. use dxf2sg3 so that I can paint/texture it in 3D editor.

4. save my sg3 file as a C file so that I can use it in my code.

And that's assuming it converts properly using dxf2sg3's triangle -> quad option.

Now imagine doing that about 37 times for a human model!

A lib for standardized stuff is an awesome idea. It means we can spend less time coding or converting & more time actually putting the game together. Its just finding someone who's got the time & skill to do it all. Hell, if it were up to me, I'd make the time regardless, buuuut I just don't have the skill for it (damn public school education! *shakes fist with rage*). But I'd help out any way I could.

Rise of the Triad over IPX...multiplayer didn't get any cooler than that back in the day.

 

[RockinB]

Originally posted by Mask of Destiny@Wed, 2005-08-24 @ 01:35 PM

I have an inprogress memory allocator that tries to handle RAM of different capabilities (including VRAM and the like). It's for a game oriented operating system I was thinking about writing. My initial target was the Sega CD, but I'm tempted to start with the Saturn first.

[post=138671]Quoted post[/post]​

Such a memory manager would be of much need for me NOW. I just made one which first uses SBL's library MEM to allocate in low work RAM and if that fails, it uses standard malloc in high work RAM. MEM is buggy and needs a re-init from time to time, so cannot use it all through my app.

I need to get a better memory manager, definitely. Maybe to even use VRAM and Cart RAM.

Is your alloc thing working?

 

[Mask of Destiny]

Basic allocation is working. I still need to write an equivalent to free() and I need to add the code that checks memory flags to make sure the memory chunk it found matches the request. I could probably get those working by the end of the week if you want to use it. It probably won't be the fastest allocator, at least not initially, but it should work all right. I'll probably need to add a couple more flag definitions for Saturn use, but that shouldn't be a big deal.

 

[RockinB]

I used BGET buffer memory allocator.

Except the priority (reflecting different RAM speeds), BGET is just THE allocator I was looking for.

It allowes me to use

- the whole free portion of high work RAM

- the whole low work RAM

- the free portion of VDP1 VRAM (may could use more)

- cartridge RAM (8MBit or 32MBit)

It's small and easy to use. Just some define's to convert function calls like malloc() to bget()...

This is great, I'm so glad now! I must have been crazy to use bzip2 on Saturn, as it eats so many memory, but now it workes flawlessly.

With cart RAM, I can increase compression quality to 2 (8MB) or even 3, 4(32MB).

A shame that my RAM cart is died .

Expect a release very soon.