Welcome to the Shining Force Central Forums!
SFC Forums Index Shining Forums Shining Fanwork
Register for your free forum account now or Login to remove this advert.

SFPC source code now available on Github

Share, discuss or get ideas for your Shining Fanwork here! Anything from fanfic and fanart to homebrew Shining games and midi composition!

SFPC source code now available on Github

Postby bludragn » Tue Sep 16 2014 2:39am

https://github.com/kenhilf/SFPC

I've decided to finally release the code for my old engine. For anyone who doesn't remember me or SFPC from a few years ago, you can read more about my efforts developing it here - http://kenhilfportfolio.blogspot.com/search/label/SFPC

Hopefully it can be of use to anyone working on their own engine, or just curious as to how SFPC works. It's possible I may come back to it to tinker again at some point, I've learned a lot in the years since I last touched it, but I don't have the time or the motivation I once did to spend on it. Now that I have my name on a professional title due to ship in the next couple months, SFPC no longer serves as the cornerstone of my resume so I feel comfortable loosening my grip on it. I'll likely get more out of it now by passing the torch to someone new or working with someone else on it than I would if I tried to continue it as a solo project.

If anyone has any questions about getting it set up or on specifics in the code, feel free to ask me here or email me directly.
bludragn

User avatar
Member
Member
 
Posts: 25
Joined: Tue Mar 30 2010 3:11am

Re: SFPC source code now available on Github

Postby Antman 537 » Sat Sep 20 2014 3:37pm

Congratulations on the title. :thumbsup:
Antman 537

User avatar
Shining Hero
Shining Hero
 
Posts: 513
Joined: Fri Aug 04 2006 7:52pm
Location: The distant future

Re: SFPC source code now available on Github

Postby TSS_Ty » Mon Sep 22 2014 3:46pm

That's great news! Thanks for taking the time to share this so others can learn.
The Shining Source - The home of Shining Force fangames
The Shining Source - The home of Shining Force fangames
TSS_Ty

User avatar
Member
Member
 
Posts: 63
Joined: Thu Sep 16 2004 4:51pm
Location: Raleigh, North Carolina

Re: SFPC source code now available on Github

Postby conlius » Mon Sep 22 2014 10:30pm

I have a code related question on this. I understand that you probably aren't monitoring this thread but I'll throw it out there...

It looks like you are doing some pass by reference with your object's draw functions (i.e. item, magic, etc) where you pass a reference to your draw engine to the member function (DrawMgr& drawMgr). Now that you have got some more background since you started, is this how you would still do it if you had to remake it?

The reason I ask is because I have a similar case with one of my projects where I am forced to pass the draw engine pointer/reference around when anything needs to be drawn to the screen. This is making it so every little object I create that needs to be drawn to the screen (i.e. potion, NPC, etc) needs to be passed the draw manager reference. My sense tells me that this is backwards and that the current gamestate you are in (menu, battle, etc) OR the object manager itself should know the draw manager's reference and call its functions with the child object as an argument, rather than passing the draw manager's reference to the child and having it call the draw function directly. Or even possibly go with uninitialized draw manager and access functions via DrawMgr::DrawObject(item& item) style? I believe some sort of approach like this would help decouple the code and make it more transferable but I can't decide and I don't want to rewrite half the engine without knowing I am going in the right direction!

Does that make any sense? Thoughts?
conlius

User avatar
Member
Member
 
Posts: 71
Joined: Thu Aug 26 2010 1:23am
Location: Boston, MA

Re: SFPC source code now available on Github

Postby bludragn » Sat Sep 27 2014 5:17pm

Passing DrawMgr refs around to each object to be drawn isn't one of the things at the top of my list to change. The actual guts of how DrawMgr draws is a whole other story though, that could use a lot of work. Right now every draw request ends up as a full blown OpenGL draw call, which is not good. Neither is my system of carving up every sprite frame and tile into its own separate texture ID, that stuff should be atlased together as much as possible. I could go on... Anyway, DrawMgr itself remains decoupled from having to know anything about game objects, it just fulfills requests to draw things no matter what is making that request.

In my engine, when it's time to draw, I think we just crawl the scene graph and pass the drawmgr ref to everything that wants or needs to draw, I don't feel like that's cumbersome. Its all done in one place in one phase, I'm not constantly hunting for access to or caching in weird places the original DrawMgr ref. Maybe it's something else about your engine's structure that's actually the problem that's causing you to have doubts about this? That being said, the two methods you suggest could probably work, nothing about them is setting off huge red flags for me. Heck, if you look at my DrawMgr code, it's really sparse, all it knows how to do is draw quads, and do some simple blending and rotation of said quads. Your method of asking it to draw Items based on Item refs would mean it gets coupled to whatvever Items are. I guess its also a matter of how important making this transferable is to you. Definitely don't rewrite half your engine unless you absolutely have to, that's how projects never get finished.
bludragn

User avatar
Member
Member
 
Posts: 25
Joined: Tue Mar 30 2010 3:11am

Re: SFPC source code now available on Github

Postby conlius » Mon Sep 29 2014 8:02pm

Thanks for the response. My thought was to abstract the crap out of my draw manager by using a base gameObject class as the argument and using it to draw all derived objects. All derived objects would have simple functions (getX, getY, getWidth, getHeight, getSprite, etc). The DrawMgr would just query the objects in the game for results (whether it be an item, character, npc, etc) and draw them to the screen. The result would be (without checking for errors):

void DrawMgr::DrawSprite (gameObject *Obj)
{
xPos = Obj->getX();
sprite = Obj->getSprite();
curFrame = Obj->getFrame();
//etc, etc, SDL or OpenGL functions to follow
}
....
gameObj *ptr = new NPC();
...init/do logic
drawEngine.DrawSprite(ptr);
...etc

Then, my draw engine really is the heart of drawing everything and my game objects only have to worry about their own logic. This isn't very difficult to adjust in my current engine but was just curious if programmers in the gaming profession do it this way.
conlius

User avatar
Member
Member
 
Posts: 71
Joined: Thu Aug 26 2010 1:23am
Location: Boston, MA

Re: SFPC source code now available on Github

Postby bludragn » Sat Oct 11 2014 11:26pm

I would counter with this - are you absolutely certain everything you draw is going to be a gameobject? What if you end up making a particle system? Individual particles probably shouldn't be gameobjects. What if you have a system where a single character is made up of multiple sprites as part of an animation, like characters and their weapons in SF battle cutscenes (just an off the top of my head example)? Will every gameobject you create always have a sprite associated with it? What does your DrawMgr do if it gets fed an object with no sprite associated? I definitely had plenty of objects in SFPC that wanted to be gameobjects so that their update fns would get called every frame, but had no graphical component. One last thing to consider, as you tack more and more features into the gameobject class, each instance of that class gets bigger and bigger and eats more memory, so if everything has to be a gameobject to get drawn, that becomes a cost you need to factor in. Just some things to think about!
bludragn

User avatar
Member
Member
 
Posts: 25
Joined: Tue Mar 30 2010 3:11am


Return to Shining Fanwork

Who is online

Users viewing this topic: No registered users and 0 guests