HomeForumsWhat's newResources 
 
 
VDP2 setup support tool, anyone?
RockinB - Nov 14, 2005
    RockinB Nov 14, 2005 
You know setting up the VDP2 scrolls can be very complicated.

Especially VRAM bank usage, cycle patterns and stuff involve a lot of background knowledge in order to make everything right.

Wouldn't it be cool to have a tool which you can tell what types of backgrounds you want and which cares about all those VDP2 specs and restrictions?

It could output SGL or SBL code to setup the VDP2 the way you want to.

What do you think? Does such a tool already exist?

    slinga Nov 14, 2005 
I feel the same way about regular sprites. I already startied writing a program that when you execute in a directory full of sprites it would create all the sprite c files for you.

    vbt Nov 14, 2005 

  
Originally posted by slinga@Mon, 2005-11-14 @ 09:49 PM

I feel the same way about regular sprites. I already startied writing a program that when you execute in a directory full of sprites it would create all the sprite c files for you.

[post=141734]Quoted post[/post]


What is the size of sprites you use ? For 8x8, 8x16 and 16x16 (with small changes) you can use the Sega MapEditor. Anyway, it woud be nice to have a such tool, the map editor doesn't make binary files.

    RockinB Nov 14, 2005 

  
Originally posted by vbt+Mon, 2005-11-14 @ 08:43 PM--><div class='quotetop'>QUOTE(vbt @ Mon, 2005-11-14 @ 08:43 PM)</div><div class='quotemain'>What is the size of sprites you use ? For 8x8, 8x16 and 16x16 (with small changes) you can use the Sega MapEditor.

[/b]



SegaConverter and 3DEditor can both export as .C file. The latter one exports as .bmp, too.

<!--QuoteBegin-v
bt@Mon, 2005-11-14 @ 08:43 PM

Anyway, it woud be nice to have a such tool, the map editor doesn't make binary files.

[post=141737]Quoted post[/post]
[/quote]

BGCON does, optionally compressed with RLE or DHUFF, even multiple files concatenated to one.

Looks like we have a lot of tools (even official ones), but........well, I would really like to have good ones which ALLOW to deal with the complicated Saturn hardware very easily. This way, using specific Saturn features would be easier and we would get better homebrew stuff.

That said: I'm curious how those two official 3D modeling tools supporting Saturn worked. If someone got Softimage, please contact me .

    vbt Nov 15, 2005 

  
Originally posted by Rockin'-B@Mon, 2005-11-14 @ 11:57 PM

If someone got Softimage, please contact me .

[post=141740]Quoted post[/post]


I've started to download Softimage 3D 3.9

Also I've found some picture of Saturn Basic tools, it looks interesting too :

http://www.ncsx.com/www/sbasic.htm...

    RockinB Nov 15, 2005 

  
Originally posted by vbt@Tue, 2005-11-15 @ 08:54 PM

I've started to download Softimage 3D 3.9

Also I've found some picture of Saturn Basic tools, it looks interesting too :

http://www.ncsx.com/www/sbasic.htm...

[post=141777]Quoted post[/post]


Oh my god.....oh my god! :smash I know some people here might own Saturn Game Basic.

    seal1 Nov 17, 2005 
would be cool such a tool.

why are people so keen for softimage ? any sega-saturn-specific plugin available for this heavy piece of soft ?

currently I´m not into any 3D-app (last time was 1996 on amiga with lightwave). but I think sticking with a smaller (free) solution would be better ?

    mrkotfw Nov 17, 2005 
setting up a background is pretty easy... look at charles' code for a good example.

here's mine: Code: 
  
#define MAP(x,y) (((x >> 13) & 0x3F) | ((y >> 5) & 0x1FFF)) // bits 0~5, 8~13 #define NBG0_PRI(n) (((n) & 0x7) << 0) #define NBG1_PRI(n) (((n) & 0x7) << 8) #define NBG2_PRI(n) NBG0_PRI(n) #define NBG3_PRI(n) NBG1_PRI(n) vdp2->r[BGON] = N3ON; // enable bg3 vdp2->r[RAMCTL] = 0x0300; // split vram-a and vram-b vdp2->r[PLSZ] = 0x0000; // 256x256 // tile format vdp2->r[CHCTLB] = 0x0000; // 16 colors for nbg3 vdp2->r[MPABN3] = MAP(NBG3_MAP_ADR,NBG3_MAP_ADR); vdp2->r[MPCDN3] = MAP(NBG3_MAP_ADR,NBG3_MAP_ADR); vdp2->r[PRINB] = NBG3_PRI(3); // nbg3 priority // nbg0 == 0x0 (map) // nbg1 == 0x1 (map) // nbg2 == 0x2 (map) // nbg3 == 0x3 (map) // CPU == 0xE // unused == 0xF // nbg0 == 0x4 (tiles) // nbg1 == 0x5 (tiles) // nbg2 == 0x6 (tiles) // nbg3 == 0x7 (tiles) // 4-bit tile access: 1 timer. E.g: 0x5 // 8-bit tile access: 2 timers. E.g: 0x55 // use BANK-A0 for tiles and map data vdp2->r[CYCA0L] = 0xFFF3; vdp2->r[CYCA0U] = 0xFFF7; // copy data (tiles and map) copy_data_fake_func(); // enable display vdp2-r[TVMD] = 0x8000; while(1) { vblank(); }

   RockinB Nov 28, 2005 

  
Originally posted by Piratero@Thu, 2005-11-17 @ 10:24 PM

setting up a background is pretty easy... look at charles' code for a good example.

here's mine:

[post=141853]Quoted post[/post]


Piratero, I don't know what kind of genius you are, but I doubt the average Saturn devver is, neither am I.

Your code looks nice and easy, but using the VDP2 is (well, interesting, but) definitely NOT EASY. So it does by far not serve the problem I'm talking about, because as soon as one wants to apply a change or addition, you have to read a lot of docs, make a lot of try and error and stuff.

Information on the VDP2 is scattered across multiple docs and even if you know all of those many restrictions,

it is most likely that you don't meet some of them, because when you change one thing, everthing else changes, too.

I would like to have a nice GUI program, which keeps track of all restrictions, provides access to ALL VDP2 features in a self-explaining way, shows were problems are when restrictions are violated and which is able to optionally try to care about all details to easy up things.

The benefit is clear: more people would use the VDP2, programs would exhaust the VDP2 power much better.

    vreuzon Dec 6, 2005 
Wouldn't it be good for the 2d graphic tool be a gimp script, as you (rockin'b) already did some parts of it ?

    RockinB Dec 13, 2005 

  
Originally posted by vreuzon@Tue, 2005-12-06 @ 12:46 PM

Wouldn't it be good for the 2d graphic tool be a gimp script, as you (rockin'b) already did some parts of it ?

[post=142262]Quoted post[/post]


From my experience, script-fu of The GIMP does not offer enough GUI functionality to realise a comprehensive tool.

The GIMP is a great tool and script-fu allows to automate everything that can be done in GIMP manually.

Nevertheless, maybe there are other useful GIMP scripts to be implemented.

    RockinB Sep 5, 2006 
I'm currently learning Tcl (again), see this image:

View attachment 3548...

    mrkotfw Sep 18, 2006 
That's great! The color address list is a bit confusing.... Are you going to be releasing this anytime soon? I'll be writing a tool very similar to this soon.

    RockinB Sep 23, 2006 

  Piratero said:
That's great! The color address list is a bit confusing.... Are you going to be releasing this anytime soon? I'll be writing a tool very similar to this soon.


It's been one of many little exercises I made to learn Tcl and Perl. It's written in Tcl and can already output the settings made to a SGL C file. It does not yet perform any assistence and error checking to ease the VDP2 usage, that's still to come.

What kind of tool are you going to create? We don't need to do the same thing twice.

    mrkotfw Sep 24, 2006 
It'll just create a binary to setup a scroll screen along with a few other things for my library.