ROLL BOSS RUSH -{Homebrew Project}-(PSX/PSone/Playstation)

You can easily drop libgs and move to full libgpu+libgte, all you need is a proper handling of a few things, such as packet allocation. From what I can recall, drawing a Tmd model with GTE macros isn't hard at all, there should be even samples from Sony (or you could even use a simplified format). And yes: libgs is slow, bloated, and just ugly in many ways. The faster you drop it the better it is.

You could also partially use libgs and only keep a few small sections from it, like graphics initialization and frame buffer handling. Those pose no problem at all for performance since they are nothing more than useful wrappers.

 

OK, i'll try to transition away from libGS. Hopefully it will give better GPU performance on real hardware (i hope)
At the very least, i know what not to use on the next game i program (thanks)

 

Great looking game. I have a couple questions to ask since I'm very interested in developing my own games for the PS1

1. Are you using the files from the online Psy-q SDK to develop and compile your game?
2. What graphics program are you using for modeling your characters and animating your backrounds?

 

Thanks

Yes

3D Studio R4 (DOS) for Modeling and texture-mapping and Milkshape for Animation and fine-tune Modeling. I go back and forth between these two programs quite a bit until a character model is complete.

Paint Tool SAI for all 2D drawings ->Backgrounds, Texture Maps, 2D- Animations, Etc.

MS Paint -> Basic Image Checking / Cropping

imv(stb) -> Basic Image viewer (a Flip Book really... to check 2D animations before finalization)

RSDTOOL -> Basic Texture Mapping / General Texture Mapping

That's about it. I don't use anything hi-tech really. Just old compatible stuff. I run 3D Studio R4 thru DOSBOX. But i compile with XP <- I'm still running XP btw

But try to keep in mind that I'm making all my assets myself plus i do all the programming. It's very time consuming. If u want to make a game and have a short turn-around i suggest u try not to do something so ambitious as this. Literally... I spend more time making assets than actual programming... which shouldn't be :-( but good luck with whatever u do

 

From this point onwards, this thread got hijacked and questions were asked about general PlayStation programming.

Whilst we are very lenient here regarding off topic posts, please refrain from completely derailing the thread with new questions. We encourage you to participate, of course - you're welcome to start your own threads with questions and someone will be happy to help.

I have moved the questions regarding general PlayStation programming here. Any further discussion in this thread should be regarding ROLL BOSS RUSH. Thanks

 

OK, here's an update... and Thanks Moderator for saving my thread from being hijacked






http://youtu.be/VGz6AyVn6zM

DownloadGame: https://www.dropbox.com/s/3we8e8v4xzpmsc6/RBR_108a.iso?dl=1
Mirror:



Source Code: https://www.dropbox.com/s/k42hn3tqhe3rkms/source_108a.rar?dl=1
Mirror:

 

http://youtu.be/TDI6QA_TWdk

I recently took a video with my smartphone of this game running on real hardware after converting over to a better polygon sorting function, GsSortobj5. I was reading thru documentation and never realized this function was faster than GsSortobj4. According to documentation this function is twice as fast when fully loaded, which i am most of the time, so i thought I'd give it a try and see how it is. Well im glad to say that it is a lot faster. I was actually able to play some bosses in melee mode at full speed but only when too many sprites weren't on the screen. I still haven't found a replace for GsSortsprite and that seems to be the function that really bottlenecks the works. Unfortunately GsSortobj5 is not without its downsides. While using it i found you couldn't duplicate/iterate one polygon model. Each polygon model has to have it's own seperate packet, something that GsSortobj4 didn't need. Also, transparency is not available. But other than those shortcomings, it is faster. The video shows actual speed on hardware, both game speed and loading speed. Hopefully i can try to get everything sorted as a polygon under this function in the future.

 

I guess I'll suggest you again to just drop Gs stuff entirely or partially: it's sluggish and hard to expand. Tmd data (or any type really) can be rendered at maximum speed by using inlined gte commands. Mind you, my engine, which doesn't rely on Gs functions to draw objects or sprites, can out about 1500 normal clipped Goraud textured polygons with zero lag. Another way to improve performance is not to use floats.

 

I've decided not to drop libgs. Although inlining gte commands improves speed, it's not as simple. I believe sn systems made libgs for the simple fact that it is simple to use. I looked thru documentation on inlining and i started to laugh. I saw one simple 1 line function elaborated into something like 100+ lines of code. This may be intriguing from an engineering standpoint to utilize nop, but for me it's not a realistic option.

 

This is a sample of my GTE inline code to draw quadrilaterals: https://gist.github.com/anonymous/8b8f3aa8f650bef5a7db
It's not really that big and it's optimized to waste as little time as possible, with a custom model format even. All games that actually wanted to push the system to its real capacity used inlined GTE commands like hell. Once you get used to them there's no way you would ever want to go back. Heck, even libhmd is way better than the basic sort functions. It's really a way more realistic option than libgs, which is slow and bloated, plus you'd understand better how the system works and you can approach it with different and better strategies.

 

All games that used 3d also ran at 30fps. If i ran at 30fps, this conversation would be moot.

 

60 fps is entirely possible if you don't have too many textured polygons or Gouraud shading, but you also need micro optimizations to make that possible (libhmd does have these, but there are way too many functions, more than you'll ever need). Many games that actually achieve that speed either don't use any shading or draw everything with POLY_Fxx types to retain a decent polycount. A profiler definitively helps with checking if your models are too dense for 60 fps; in general the rule is that you have half the time to draw everything, so it's half the polygons as well.

 

I just found something else out about GsSortObj5. Seems that you can't sort an object if it doesn't exist on memory. I usually prototype with empty 3D model addresses and i never had a problem with GsSortObj4 but for some reason GsSortObj5 will lock up. This is just something else I need to keep in mind as I move forward with GsSortObj5.

 

I assume the lockup issue comes from packet allocation gone wrong? I can also see why GsSortObj5 can be faster than 4 at this point, since it doesn't require any updates to polygon data like uv maps.

 

Yeah, GsSortObj5 really is sufficient enough to create a great game (if everything goes through it of course) After i finish making the end boss, I'm going to make a game that runs entirely off of GsSortObj5.

P.s.

Side note... prototyping is going well. I'll post a quick video of what it looks like at the moment (hopefully soon)

 

By the way, have you yet considered the idea of trimming all the executables of Roll's game into a single one with overlays? I'd be tempted to contribute somehow to the project to maximize some of the resources. Rarely you find something like this around in the PSX scene.

 

Yes, i have considered it and read up on it too. From my understanding the Parent EXE is loaded into memory with the Child EXE requirements in mind. I still haven't experimented with it yet, but i do want to try. If i have any problems i won't hesitate to ask you.

BTW. Here's a video on my progress so far.

http://youtu.be/UJqLAcUjVPs?list=UUOGNwek_RxLGzuZ6PJ1_ADA

 

More or less it's like what you described, only it's not EXE processes but binary slices of the engine itself. The best thing about it is that you can keep the main logic into the main EXE (along with libraries and general engine procedures such as rendering) while everything else resides in these slices which can be loaded on demand, either as stacking pieces (separate tasks, say a menu or boot sequence) or replacement modules. For example, you could code the AI for a boss at the same loading address of another boss, switch them as necessary, and have just one area of memory swapping around tasks. This helps a lot in keeping your code clean and scope-based, it also results in much faster caching of data.

 

Little updated.

I got a lot done over the weekend. I'm actually almost done. The 3d model is done for the most part and the ai is all set. I just need to add some weapons and special effects and I'll be done. I still haven't painted the room yet, but I'm tempted to just release it just like it is so i can have a playable version out for testing. We'll see.. 2

 

Had to remodel the model over the weekend cause it was not displaying correctly with the new camera perspective. Almost there, but not quite yet...