Elysian Shadows

kamokow wrote:MrDeathNote: Provided you have firmware 5.03 or lower, upgrade to 5.03 if necissary, run ChickHEN r2, run a CFW installer compatable with the motherboards on PSP-3000 (I use 5.03 M33). But if you turn of the PSP, you have to re-install the CFW until someone in the dev community comes up with an exploit that works better.

This

eatcomics wrote:

kamokow wrote:MrDeathNote: Provided you have firmware 5.03 or lower, upgrade to 5.03 if necissary, run ChickHEN r2, run a CFW installer compatable with the motherboards on PSP-3000 (I use 5.03 M33). But if you turn of the PSP, you have to re-install the CFW until someone in the dev community comes up with an exploit that works better.

This

Seems like you would be better developing on an emulator than not being able to turn off you psp, then use the psp to test when you have something really good.

MrDeathNote wrote:

eatcomics wrote:

kamokow wrote:MrDeathNote: Provided you have firmware 5.03 or lower, upgrade to 5.03 if necissary, run ChickHEN r2, run a CFW installer compatable with the motherboards on PSP-3000 (I use 5.03 M33). But if you turn of the PSP, you have to re-install the CFW until someone in the dev community comes up with an exploit that works better.

This

Seems like you would be better developing on an emulator than not being able to turn off you psp, then use the psp to test when you have something really good.

/agreed

Also if you debug your homebrews on an emulator, there could be less chance that you brick your psp

I was actually thinking about tinkering with the SDK on an emu, so I'll know some stuff if and when I get mine jailbroken :D

Update:

~Did a Little Work on the 2D parts of the Engine, the Engine is Mostly 3D but wanted to Expand and I was bored :P
--
~Working on a Console Class and Engine Commands, Similar to Source Engine
~Writing Some More Client-Server Stuff that Can be Used Ingame Effectively
~Still Implementing/Improving Editor & Viewer Functionality
~Start Playing with other Model Formats like MD5 e.g. Hellknight

#Gunna Learn Some More About Bump Mapping & Point Lights / Shadows, etc..

Shadowing will be tricky to implement, but once you get it I bet it will look real cool. This is one of the next things I'm trying to get done right in my own engine, so good luck with it. But looks like you're more ahead of me with your picking system and map builder.

Does your engine use shaders for rendering or is it just a fixed function pipeline?

CC Ricers wrote:Shadowing will be tricky to implement, but once you get it I bet it will look real cool. This is one of the next things I'm trying to get done right in my own engine, so good luck with it. But looks like you're more ahead of me with your picking system and map builder.

Does your engine use shaders for rendering or is it just a fixed function pipeline?

Thanks

My engine is still fixed function. But I've already got to work on the changes your right though shadows and other effects are damn tricky to do, but they would look hella awesome once done! =D

Great update!
2 questions:

How do you load md5 models? Are you using a lib? Any reference would be nice!

The console looks like the one in source...no - its exactly the same ;D
Is this just a single window or did you wrote a whole GUI System?

Milch wrote:Great update!
2 questions:

How do you load md5 models? Are you using a lib? Any reference would be nice!

Thanks!
I learned some stuff from http://www.fabiensanglard.net/bumpMapping/index.php the animation is fucked up though =P
**MD5 is what I would consisder a Advanced Model Format, this is because it has bone animation amongst other things**
This is why I got confortable with MD2 and OBJ first

Milch wrote:The console looks like the one in source...no - its exactly the same ;D
Is this just a single window or did you wrote a whole GUI System?

Ye I was just messing around, so I took a screenshot of Source Engine console and coded a Console Class that uses my 'GUI System' so to speak.
**My Console Class uses**
~My Input Class to get the user Keyboard input
~The GUI Class for rendering the Console to the Screen
~And the Text Class to update/render the 'Current' command or Input AND update/render the 'Stack' of previous commands or inputs

Edit: Don't sue me Valve

GroundUpEngine wrote: Edit: Don't sue me Valve

Epic updates. Can't wait to use this engine :D

GroundUpEngine wrote: Edit: Don't sue me Valve

ROFL i'm sure you'll be fine

I can't find the post where you mentioned what you had replaced the singletons with, but I'll throw in my design ideologies.

Your DebugLog/Debug singleton is completely justified in its singleton-ness. I also have one in Elysian Shadows that serves a similar purpose. It's a friend class to everything, so that at any point in development I can pop an instance out of my ass, grab references to any entity, dump some debug output, and get on with my day. It's pretty nifty to have.

Your Window (I think it was) might be a little bit less justified in being a singleton. I'm not sure how your engine is structured, but ES (and most) are something like:
With this design, I'm able to REGISTER interdependencies upon engine initialization. Something like: So now, the subsystems can have local pointers to interdependent subsystems. Interdependency is inevitable in software development--especially in game development. It's not a matter of never allowing it, it's just a matter of gracefully handling it. Allowing a system to pull a renderer singleton out of its asshole is far less gracious than having a documented, registered dependency on the renderer and allowing it to contain a pointer.

Thanks man!! Great explanation, I totally understand this now

That's a really good explanation. Well, i understand it better anyway...

So question, would I be better off using a debug singleton, or a debug class that everything inherits from??? I would really love to hear an answer and explanation :D Seeing as how I'm going to be doing some 3D stuff, and would really love to be able to have some good debug...