Secret Maryo Chronicles

This is a forum for discussing the feasibility of getting emulators, games, or other applications that have had their source released ported to the Dreamcast. Please read the Porting FAQ before starting a topic in this forum!
User avatar
PH3NOM
DC Developer
DC Developer
Posts: 576
https://www.artistsworkshop.eu/meble-kuchenne-na-wymiar-warszawa-gdzie-zamowic/
Joined: Fri Jun 18, 2010 9:29 pm
Has thanked: 0
Been thanked: 5 times

Re: Secret Maryo Chronicles

Post by PH3NOM »

Basil wrote:
I would probably need some help in converting the maps to the format I am using for DC, as it can be a bit time consuming.
If anyone is interested in helping, drop me a line.
If it doesnt require programming knowledge i can try to.
New beta looks awesome. I cant wait to see a full level. :)
Thanks again for the interest, but we can scratch that idea off of the list.

I have actually written an app to convert the .smclvl format into the map format I am using on DC.
This means the maps will be exactly the same as the standard version of the game.
Still a few details to iron out, but this is very good news for the project indeed.

Image
dreamcast-news
DCEmu Freak
DCEmu Freak
Posts: 54
Joined: Tue Aug 30, 2011 3:29 am
Has thanked: 0
Been thanked: 0

Re: Secret Maryo Chronicles

Post by dreamcast-news »

Good news PH3NOM :grin:
Good luck.
User avatar
Basil
Insane DCEmu
Insane DCEmu
Posts: 200
Joined: Wed Apr 09, 2008 9:04 am
Has thanked: 13 times
Been thanked: 0
Contact:

Re: Secret Maryo Chronicles

Post by Basil »

Oh, it's good that you have created an easy way to work with maps. I'm very excited about your project.
User avatar
Maturion
Moderator
Moderator
Posts: 619
Joined: Fri Oct 12, 2007 1:52 pm
Location: Munich, Germany
Has thanked: 0
Been thanked: 0
Contact:

Re: Secret Maryo Chronicles

Post by Maturion »

Awesome stuff! :)
User avatar
PH3NOM
DC Developer
DC Developer
Posts: 576
Joined: Fri Jun 18, 2010 9:29 pm
Has thanked: 0
Been thanked: 5 times

Re: Secret Maryo Chronicles

Post by PH3NOM »

Progress continues! Stay tuned.

Image

Image

Image
dreamcast-news
DCEmu Freak
DCEmu Freak
Posts: 54
Joined: Tue Aug 30, 2011 3:29 am
Has thanked: 0
Been thanked: 0

Re: Secret Maryo Chronicles

Post by dreamcast-news »

We follow you. :)
User avatar
Basil
Insane DCEmu
Insane DCEmu
Posts: 200
Joined: Wed Apr 09, 2008 9:04 am
Has thanked: 13 times
Been thanked: 0
Contact:

Re: Secret Maryo Chronicles

Post by Basil »

Thank you for new screenshots.
law56ker
DCEmu Cool Poster
DCEmu Cool Poster
Posts: 1034
Joined: Wed Oct 17, 2001 7:44 pm
Has thanked: 0
Been thanked: 1 time

Re: Secret Maryo Chronicles

Post by law56ker »

Wow, cool, nice to see that this is being worked on :)
User avatar
PH3NOM
DC Developer
DC Developer
Posts: 576
Joined: Fri Jun 18, 2010 9:29 pm
Has thanked: 0
Been thanked: 5 times

Re: Secret Maryo Chronicles

Post by PH3NOM »

Well, I guess I'll upload the 2nd demo.
Keep in mind it is totally my own... If anyone is really interested I can share some code.
Good progress considering I have been working on this for just over a month in my free time.

Get it here:
http://www.mediafire.com/?58i1xo8fvjryhrn

Image
User avatar
Indiket
DC Developer
DC Developer
Posts: 99
Joined: Sun Sep 05, 2010 5:44 am
Has thanked: 0
Been thanked: 0

Re: Secret Maryo Chronicles

Post by Indiket »

Nice tech-demo PH3NOM! It's getting better :) . Do you know when we'll start smashing mushrooms and losing lives? ;)
User avatar
Neoblast
DC Developer
DC Developer
Posts: 314
Joined: Sat Dec 01, 2007 8:51 am
Has thanked: 3 times
Been thanked: 1 time

Re: Secret Maryo Chronicles

Post by Neoblast »

Wow that really is nice Ph3n0m.

I tried it and I must say it's quite impressive :)

Should we expect a full engine/game in the near future?
User avatar
PH3NOM
DC Developer
DC Developer
Posts: 576
Joined: Fri Jun 18, 2010 9:29 pm
Has thanked: 0
Been thanked: 5 times

Re: Secret Maryo Chronicles

Post by PH3NOM »

Neoblast wrote:Wow that really is nice Ph3n0m.

I tried it and I must say it's quite impressive :)

Should we expect a full engine/game in the near future?
Thanks!

I had problems with running the larger levels at 60fps, some slowdown could drop down to 55fps, also causing issues with music playback.

Anyhow, I realized there was a limitation in the way the PVR is being utilized by KOS.

I have solved the problem, and now things are faster than ever.

Image
patbier
DC Developer
DC Developer
Posts: 152
Joined: Fri Aug 29, 2003 1:25 am
Has thanked: 0
Been thanked: 0

Re: Secret Maryo Chronicles

Post by patbier »

PH3NOM wrote: Anyhow, I realized there was a limitation in the way the PVR is being utilized by KOS.
I have solved the problem, and now things are faster than ever.

Great ! Can you say more about the PVR limitation and the way you solved it ?
ImageAlice Dreams Tournament Dreamcast fans : http://www.facebook.com/alicedreamst
In August 2015, we had to change "Dynamite Dreams" name to "Alice Dreams Tournament"
User avatar
Neoblast
DC Developer
DC Developer
Posts: 314
Joined: Sat Dec 01, 2007 8:51 am
Has thanked: 3 times
Been thanked: 1 time

Re: Secret Maryo Chronicles

Post by Neoblast »

patbier wrote:
PH3NOM wrote: Anyhow, I realized there was a limitation in the way the PVR is being utilized by KOS.
I have solved the problem, and now things are faster than ever.

Great ! Can you say more about the PVR limitation and the way you solved it ?
I'm intrigued about that too... did you modify kos for that?
User avatar
PH3NOM
DC Developer
DC Developer
Posts: 576
Joined: Fri Jun 18, 2010 9:29 pm
Has thanked: 0
Been thanked: 5 times

Re: Secret Maryo Chronicles

Post by PH3NOM »

Neoblast wrote:
patbier wrote:
PH3NOM wrote: Anyhow, I realized there was a limitation in the way the PVR is being utilized by KOS.
I have solved the problem, and now things are faster than ever.

Great ! Can you say more about the PVR limitation and the way you solved it ?
I'm intrigued about that too... did you modify kos for that?
Sorry to get your hopes up, my solution was really simple.
The thing is, the PVR is limited to 60fps. ( I dont know if this is a hardware limitation, or KOS ).
However, the engine I'm writing is capable of much faster than that.
What I was doing is simply rendering every-other frame, so 100 frames processed by the engine meant 50 frames drawn per second.

As things turn out, I decided to try PVR Direct Rendering instead of the other PVR Primitive method.
Success!
Now, even on the larger levels, everything runs smoothly at 60fps, rendering every frame.

So, remember folks, if you are pushing thousands of polys per frame, make sure to use Direct Rendering!

To summarize:
Before, the scene was rendered in two phases.
1 - Compile the polys

Code: Select all

void DCE_compile_l1( LevelSprite_t current, int entries )
{
    int i;
    for( i=0; i<entries; i++ ) 
       pvr_compile_l1( &current[i], 10.0f );                                             
}

Code: Select all

inline pvr_compile_l1( LevelSprite_t sprite, float z )
{
    sprite->frame.vert[0].argb  = sprite->frame.vert[1].argb  = sprite->frame.vert[2].argb  = sprite->frame.vert[3].argb  = PVR_PACK_COLOR(1.0f, 1.0f, 1.0f, 1.0f);
    sprite->frame.vert[0].z     = sprite->frame.vert[1].z     = sprite->frame.vert[2].z     = sprite->frame.vert[3].z     = z;    
    sprite->frame.vert[0].flags = sprite->frame.vert[1].flags = sprite->frame.vert[2].flags = PVR_CMD_VERTEX;
    sprite->frame.vert[3].flags = PVR_CMD_VERTEX_EOL; 

	 sprite->frame.vert[0].x = sprite->frame.vert[1].x = sprite->x;
    sprite->frame.vert[0].y = sprite->frame.vert[2].y = sprite->y+sprite->height;
    sprite->frame.vert[0].v = sprite->frame.vert[2].v = sprite->frame.height_ratio;
    sprite->frame.vert[1].y = sprite->frame.vert[3].y = sprite->y; 
    sprite->frame.vert[2].u = sprite->frame.vert[3].u = sprite->frame.width_ratio; 
    sprite->frame.vert[2].x = sprite->frame.vert[3].x = sprite->x+sprite->width;

	pvr_poly_cxt_txr(&sprite->frame.cxt, PVR_LIST_TR_POLY, sprite->frame.texColor | sprite->frame.texFmt,
		                   sprite->frame.vram_width, sprite->frame.vram_height, sprite->frame.vram_tex, PVR_FILTER_BILINEAR);
	pvr_poly_compile(&sprite->frame.poly, &sprite->frame.cxt);
}
2 - Submit the polys

Code: Select all

void DCE_submit_l1( LevelSprite_t, int elements )
{
     int i;
     for (i=0; i<elements; i++ )
          pvr_submit_poly( sprite[i].frame );
}

Code: Select all

inline pvr_submit_poly( struct pvr_frame pvr  )
{
	pvr_prim(&pvr.poly, sizeof(pvr.poly));

	pvr_prim(&pvr.vert[0], sizeof(pvr.vert[0]));
	pvr_prim(&pvr.vert[1], sizeof(pvr.vert[1]));
	pvr_prim(&pvr.vert[2], sizeof(pvr.vert[2]));
	pvr_prim(&pvr.vert[3], sizeof(pvr.vert[3]));
}
That works fine, but slows way down when pushing thousands of polys per frame.

Now, I am using a 1-pass Direct Render method:

Code: Select all

void DCE_render_l1( LevelSprite_t current, int entries )
{
    int i;
    for( i=0; i<entries; i++ ) 
       pvr_direct_render_l1( &current[i], 10.0f );                                             
}

Code: Select all

inline pvr_direct_render_l1( LevelSprite_t sprite, float z )
{
      pvr_vertex_t *vert;
      pvr_dr_state_t state;

	  pvr_poly_cxt_txr(&sprite->frame.cxt, PVR_LIST_TR_POLY, sprite->frame.texColor | sprite->frame.texFmt,
		                   sprite->frame.vram_width, sprite->frame.vram_height, sprite->frame.vram_tex, PVR_FILTER_BILINEAR);
	  pvr_poly_compile(&sprite->frame.poly, &sprite->frame.cxt);

      pvr_dr_init(state);
      pvr_prim(&sprite->frame.poly, sizeof(pvr_poly_hdr_t));  

      vert = pvr_dr_target(state);
      vert->flags = PVR_CMD_VERTEX;
      vert->x = sprite->x;
      vert->y = sprite->y+sprite->height;
      vert->z = z;
      vert->u = 0;
      vert->v = sprite->frame.height_ratio; 
      vert->argb = 0xffffffff;
      pvr_dr_commit(vert);

      vert = pvr_dr_target(state);
      vert->flags = PVR_CMD_VERTEX;
      vert->x = sprite->x; 
      vert->y = sprite->y; 
      vert->z = z;
      vert->u = 0;
      vert->v = 0;
      vert->argb = 0xffffffff;
      pvr_dr_commit(vert);

      vert = pvr_dr_target(state);
      vert->flags = PVR_CMD_VERTEX;
      vert->x = sprite->x+sprite->width;
      vert->y = sprite->y+sprite->height;
      vert->z = z;
      vert->u = sprite->frame.width_ratio; 
      vert->v = sprite->frame.height_ratio; 
      vert->argb = 0xffffffff;
      pvr_dr_commit(vert);

      vert = pvr_dr_target(state);
      vert->flags = PVR_CMD_VERTEX_EOL;
      vert->x = sprite->x+sprite->width;
      vert->y = sprite->y;
      vert->z = z;
      vert->u = sprite->frame.width_ratio; 
      vert->v = 0;
      vert->argb = 0xffffffff;
      pvr_dr_commit(vert);
} 
And this is very fast! Constant 60fps.
User avatar
Neoblast
DC Developer
DC Developer
Posts: 314
Joined: Sat Dec 01, 2007 8:51 am
Has thanked: 3 times
Been thanked: 1 time

Re: Secret Maryo Chronicles

Post by Neoblast »

Hum it looks very nice and fast indeed, but wasn't the other way used for some reason?

Maybe you are skipping some control checks/functions that could lead to some errors when rendering polys or something?

Else everything would have been done using that method, right?

I haven't tangled too much with direct rendering so correct me if I'm wrong.
User avatar
PH3NOM
DC Developer
DC Developer
Posts: 576
Joined: Fri Jun 18, 2010 9:29 pm
Has thanked: 0
Been thanked: 5 times

Re: Secret Maryo Chronicles

Post by PH3NOM »

Neoblast wrote:Hum it looks very nice and fast indeed, but wasn't the other way used for some reason?

Maybe you are skipping some control checks/functions that could lead to some errors when rendering polys or something?

Else everything would have been done using that method, right?

I haven't tangled too much with direct rendering so correct me if I'm wrong.
No, that's not the reason :-) Although I am not exactly sure myself. Maybe someone can correct me too!
( BB Hood, you still around? viewtopic.php?f=29&t=100316 )

There may be more to it than this, but here is my understanding of the difference...

With the primitive method, a polygon that is compiled can be submitted for display over and over again without re-compiling the poly.
Only if the coordinates change does the poly need to be compiled again before it can be submitted for display.
This mode could be optimal for GUI's, or static display such as health bar, on-screen displays, etc.

With the Direct Render method, a polygon is compiled directly into the display list. It cant be used again without re-compiling.
This mode is optimal for polygons that continually change coordinates.

Not sure on a hardware level what is actually happening, but I can say for sure that Direct Rendering has greatly increased render speed in my engine ;-)
Why doesn't everything use it? Good question. I don't see it used in any of the KOS PVR examples I have looked at...
User avatar
Neoblast
DC Developer
DC Developer
Posts: 314
Joined: Sat Dec 01, 2007 8:51 am
Has thanked: 3 times
Been thanked: 1 time

Re: Secret Maryo Chronicles

Post by Neoblast »

PH3NOM wrote:
Neoblast wrote:Hum it looks very nice and fast indeed, but wasn't the other way used for some reason?

Maybe you are skipping some control checks/functions that could lead to some errors when rendering polys or something?

Else everything would have been done using that method, right?

I haven't tangled too much with direct rendering so correct me if I'm wrong.
No, that's not the reason :-) Although I am not exactly sure myself. Maybe someone can correct me too!
( BB Hood, you still around? viewtopic.php?f=29&t=100316 )

There may be more to it than this, but here is my understanding of the difference...

With the primitive method, a polygon that is compiled can be submitted for display over and over again without re-compiling the poly.
Only if the coordinates change does the poly need to be compiled again before it can be submitted for display.
This mode could be optimal for GUI's, or static display such as health bar, on-screen displays, etc.

With the Direct Render method, a polygon is compiled directly into the display list. It cant be used again without re-compiling.
This mode is optimal for polygons that continually change coordinates.

Not sure on a hardware level what is actually happening, but I can say for sure that Direct Rendering has greatly increased render speed in my engine ;-)
Why doesn't everything use it? Good question. I don't see it used in any of the KOS PVR examples I have looked at...
Humm it sure is interesting and maybe an example should be uploaded to the kos svn?

A good way to test would be a "stress test" of the engine with/without (primitive method /new) plus static and moving polygons then checking the framerate.

Have you tried if its faster with static onesas well?
User avatar
PH3NOM
DC Developer
DC Developer
Posts: 576
Joined: Fri Jun 18, 2010 9:29 pm
Has thanked: 0
Been thanked: 5 times

Re: Secret Maryo Chronicles

Post by PH3NOM »

Neoblast wrote:Humm it sure is interesting and maybe an example should be uploaded to the kos svn?

A good way to test would be a "stress test" of the engine with/without (primitive method /new) plus static and moving polygons then checking the framerate.

Have you tried if its faster with static onesas well?
Actually took another look today, and KOS does actually does have an example using Direct Rendering, and this example actually helped me make one important optimization to my rendering code:

Code: Select all

kos\examples\dreamcast\pvr\pvrmark_strips_direct
And looking closer at the KOS API, it makes perfect sense why this method works faster:
http://gamedev.allusion.net/docs/kos-cu ... 154aefe77b
Post Reply