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: 573
Joined: Fri Jun 18, 2010 9:29 pm

Re: Secret Maryo Chronicles

Post by PH3NOM » Fri Apr 13, 2012 8:11 pm

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: 52
Joined: Tue Aug 30, 2011 3:29 am

Re: Secret Maryo Chronicles

Post by dreamcast-news » Sat Apr 14, 2012 6:27 am

Good news PH3NOM :grin:
Good luck.
User avatar
Basil
Insane DCEmu
Insane DCEmu
Posts: 199
Joined: Wed Apr 09, 2008 9:04 am
Contact:

Re: Secret Maryo Chronicles

Post by Basil » Sat Apr 14, 2012 4:06 pm

Oh, it's good that you have created an easy way to work with maps. I'm very excited about your project.
{Vodz@DC} @ Sylverant, VasiliyDC @ Quake3
Order Dux 1.0, Redux incl. Dux 1.5 and The Ghost Blade at http://hucast.com/index.php
Buy more independent Dreamcast games:
https://www.goatstore.com/Products/Sega ... elopments/
https://www.dragonbox.de/en/52-games#/system-dreamcast
User avatar
Maturion
Moderator
Moderator
Posts: 617
Joined: Fri Oct 12, 2007 1:52 pm
Location: Munich, Germany
Contact:

Re: Secret Maryo Chronicles

Post by Maturion » Sun Apr 15, 2012 9:21 am

Awesome stuff! :)
User avatar
PH3NOM
DC Developer
DC Developer
Posts: 573
Joined: Fri Jun 18, 2010 9:29 pm

Re: Secret Maryo Chronicles

Post by PH3NOM » Sat Apr 21, 2012 9:09 pm

Progress continues! Stay tuned.

Image

Image

Image
dreamcast-news
DCEmu Freak
DCEmu Freak
Posts: 52
Joined: Tue Aug 30, 2011 3:29 am

Re: Secret Maryo Chronicles

Post by dreamcast-news » Sun Apr 22, 2012 2:17 pm

We follow you. :)
User avatar
Basil
Insane DCEmu
Insane DCEmu
Posts: 199
Joined: Wed Apr 09, 2008 9:04 am
Contact:

Re: Secret Maryo Chronicles

Post by Basil » Sun Apr 22, 2012 3:20 pm

Thank you for new screenshots.
{Vodz@DC} @ Sylverant, VasiliyDC @ Quake3
Order Dux 1.0, Redux incl. Dux 1.5 and The Ghost Blade at http://hucast.com/index.php
Buy more independent Dreamcast games:
https://www.goatstore.com/Products/Sega ... elopments/
https://www.dragonbox.de/en/52-games#/system-dreamcast
law56ker
DCEmu Cool Poster
DCEmu Cool Poster
Posts: 1022
Joined: Wed Oct 17, 2001 7:44 pm

Re: Secret Maryo Chronicles

Post by law56ker » Mon Apr 23, 2012 1:23 am

Wow, cool, nice to see that this is being worked on :)
User avatar
PH3NOM
DC Developer
DC Developer
Posts: 573
Joined: Fri Jun 18, 2010 9:29 pm

Re: Secret Maryo Chronicles

Post by PH3NOM » Sun Apr 29, 2012 9:49 pm

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

Re: Secret Maryo Chronicles

Post by Indiket » Mon Apr 30, 2012 2:04 pm

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: 311
Joined: Sat Dec 01, 2007 8:51 am

Re: Secret Maryo Chronicles

Post by Neoblast » Sun May 06, 2012 9:58 am

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: 573
Joined: Fri Jun 18, 2010 9:29 pm

Re: Secret Maryo Chronicles

Post by PH3NOM » Thu May 10, 2012 10:55 pm

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

Re: Secret Maryo Chronicles

Post by patbier » Fri May 11, 2012 12:26 am

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: 311
Joined: Sat Dec 01, 2007 8:51 am

Re: Secret Maryo Chronicles

Post by Neoblast » Fri May 11, 2012 2:02 pm

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: 573
Joined: Fri Jun 18, 2010 9:29 pm

Re: Secret Maryo Chronicles

Post by PH3NOM » Sun May 13, 2012 12:53 pm

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: 311
Joined: Sat Dec 01, 2007 8:51 am

Re: Secret Maryo Chronicles

Post by Neoblast » Sun May 13, 2012 2:14 pm

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: 573
Joined: Fri Jun 18, 2010 9:29 pm

Re: Secret Maryo Chronicles

Post by PH3NOM » Sun May 13, 2012 7:01 pm

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: 311
Joined: Sat Dec 01, 2007 8:51 am

Re: Secret Maryo Chronicles

Post by Neoblast » Sun May 13, 2012 8:37 pm

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: 573
Joined: Fri Jun 18, 2010 9:29 pm

Re: Secret Maryo Chronicles

Post by PH3NOM » Sun May 20, 2012 8:51 pm

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