ROLL BOSS RUSH -{Homebrew Project}- (PSX/PSone/Playstation)
Forum rules
Do not submit your PlayStation games or programs here!
Please submit them under 'Homebrew (General)'.
Do not submit your PlayStation games or programs here!
Please submit them under 'Homebrew (General)'.
ROLL BOSS RUSH -{Homebrew Project}- (PSX/PSone/Playstation)
ROLL BOSS RUSH (HOMEBREW PROJECT)
Username: Isufje
Project Title: ROLL BOSS RUSH
Time to Complete: -
SDK: PSY-Q
Genre: Action
In Development: In Development
Last Date Updated: xx-xx-xxxx
Controller: CONTROL PAD
Players: 1
Memory Card: 0 Block
Languages: English
Burn and Play: Yes
Executable Included: No
Source Included: Yes
This is an ongoing project of mine. I've tested and debugged it pretty thoroughly, but you never know. If it freezes on you or refuses to load, please let me know.
Based on the Roll from the Megaman cartoon. You play as Roll, fighting difficult robo bosses in effort to stop Dr. Wily from taking over the world. If you can think of a better story... tell me.
You can play it on ePSXe at 640x480 or real Hardware at 320x240 only.
UPDATED 12-29-2015
DownloadGame: https://www.dropbox.com/s/plw55ayog3iru4z/rbr_110a.rar?dl=1
Source Code: https://www.dropbox.com/s/9304ssd7fa11zat/source_110a.rar?dl=1
Youtube - Glitches http://www.youtube.com/watch?v=Bg0xstPVPGw
Any feedback would be nice.
Last edited by isufje on December 30th, 2015, 4:06 pm, edited 25 times in total.
-
Shadow Verified
- Admin / PSXDEV
- Posts: 2670
- Joined: Dec 31, 2012
- PlayStation Model: H2000/5502
- Discord: Shadow^PSXDEV
That is very cool. Did you start making the game this year?
Development Console: SCPH-5502 with 8MB RAM, MM3 Modchip, PAL 60 Colour Modification (for NTSC), PSIO Switch Board, DB-9 breakout headers for both RGB and Serial output and an Xplorer with CAETLA 0.34.
PlayStation Development PC: Windows 98 SE, Pentium 3 at 400MHz, 128MB SDRAM, DTL-H2000, DTL-H2010, DTL-H201A, DTL-S2020 (with 4GB SCSI-2 HDD), 21" Sony G420, CD-R burner, 3.25" and 5.25" Floppy Diskette Drives, ZIP 100 Diskette Drive and an IBM Model M keyboard.
PlayStation Development PC: Windows 98 SE, Pentium 3 at 400MHz, 128MB SDRAM, DTL-H2000, DTL-H2010, DTL-H201A, DTL-S2020 (with 4GB SCSI-2 HDD), 21" Sony G420, CD-R burner, 3.25" and 5.25" Floppy Diskette Drives, ZIP 100 Diskette Drive and an IBM Model M keyboard.
I've been working on this and a couple of other things off and on since 2008. I half made the engine in late 2008 then left it alone for over a year. The first source code on my computer labeled "ROLL_001a.c" is dated 9/3/2010 so...
-
Shadow Verified
- Admin / PSXDEV
- Posts: 2670
- Joined: Dec 31, 2012
- PlayStation Model: H2000/5502
- Discord: Shadow^PSXDEV
Well you have done an amazing job. Keep up the great work!
I will add it to the PSXDEV homepage and into the Homebrew section soon.
I will add it to the PSXDEV homepage and into the Homebrew section soon.
Development Console: SCPH-5502 with 8MB RAM, MM3 Modchip, PAL 60 Colour Modification (for NTSC), PSIO Switch Board, DB-9 breakout headers for both RGB and Serial output and an Xplorer with CAETLA 0.34.
PlayStation Development PC: Windows 98 SE, Pentium 3 at 400MHz, 128MB SDRAM, DTL-H2000, DTL-H2010, DTL-H201A, DTL-S2020 (with 4GB SCSI-2 HDD), 21" Sony G420, CD-R burner, 3.25" and 5.25" Floppy Diskette Drives, ZIP 100 Diskette Drive and an IBM Model M keyboard.
PlayStation Development PC: Windows 98 SE, Pentium 3 at 400MHz, 128MB SDRAM, DTL-H2000, DTL-H2010, DTL-H201A, DTL-S2020 (with 4GB SCSI-2 HDD), 21" Sony G420, CD-R burner, 3.25" and 5.25" Floppy Diskette Drives, ZIP 100 Diskette Drive and an IBM Model M keyboard.
- CosmoGuy
- Serious PSXDEV User
- Posts: 91
- Joined: May 30, 2012
- I am a: Hell knows who I am
- PlayStation Model: SCPH-7502
- Location: Polska, Wroclaw
- Contact:
Dude!
I dont know how old are you but DAMN THIS IS F*CKIN' PRO.
Super Respect from me to you. A big +.
Specially that moment when is "power absorb". It just cherry on the cake. It's done so good. You could sell it back then.
I dont know how old are you but DAMN THIS IS F*CKIN' PRO.
Super Respect from me to you. A big +.
Specially that moment when is "power absorb". It just cherry on the cake. It's done so good. You could sell it back then.
thanx... for making me feel old! j/k ((( I'm 29 >_< ))) But yeah, i appreciate the comment. The power absorb kinda has that "Valkyrie Profile soul search" thing going at the end.
-
Shadow Verified
- Admin / PSXDEV
- Posts: 2670
- Joined: Dec 31, 2012
- PlayStation Model: H2000/5502
- Discord: Shadow^PSXDEV
My gosh. Such terrible loading times
Development Console: SCPH-5502 with 8MB RAM, MM3 Modchip, PAL 60 Colour Modification (for NTSC), PSIO Switch Board, DB-9 breakout headers for both RGB and Serial output and an Xplorer with CAETLA 0.34.
PlayStation Development PC: Windows 98 SE, Pentium 3 at 400MHz, 128MB SDRAM, DTL-H2000, DTL-H2010, DTL-H201A, DTL-S2020 (with 4GB SCSI-2 HDD), 21" Sony G420, CD-R burner, 3.25" and 5.25" Floppy Diskette Drives, ZIP 100 Diskette Drive and an IBM Model M keyboard.
PlayStation Development PC: Windows 98 SE, Pentium 3 at 400MHz, 128MB SDRAM, DTL-H2000, DTL-H2010, DTL-H201A, DTL-S2020 (with 4GB SCSI-2 HDD), 21" Sony G420, CD-R burner, 3.25" and 5.25" Floppy Diskette Drives, ZIP 100 Diskette Drive and an IBM Model M keyboard.
Yeah, my older brother had the same problem. He also noted that the character's chests were too big. I don't know what i can do about the chests, but I'll be uploading some better source soon with a better work around with loading times.
OK, here's a better version.
The gameover Layout is more intuitive now. Your not forced to go to stage select anymore. It let's you fight the same boss over again which cuts the loading times since it doesn't have to reload everything. The new load indicator is also very helpful/distracting ^_^. I'll update all links once everything's done uploading
The gameover Layout is more intuitive now. Your not forced to go to stage select anymore. It let's you fight the same boss over again which cuts the loading times since it doesn't have to reload everything. The new load indicator is also very helpful/distracting ^_^. I'll update all links once everything's done uploading
Last edited by isufje on July 1st, 2012, 5:50 am, edited 2 times in total.
I'll try to put more comments and stuff to explain functions, but I like to comment out a lot of functions just because they'll be useful later on.
If you want to do some tests, try this...
open ICE_CODE.h
goto the start of game play : line 618
add WEAPON_QUICK_FLG=ON; before the start of the game loop so that it's on before the loop
save it.
compile ICE2m.c at starting address 0x8001A000
rename main.exe to ICE2.exe
replace the existing ICE2.exe in the game ISO with your new version
Make another ISO with your new file
Now test it out to see if you did it right. You should be able to use QUICK from the menu while playing ICE WOMAN.
If you want to do some tests, try this...
open ICE_CODE.h
goto the start of game play : line 618
add WEAPON_QUICK_FLG=ON; before the start of the game loop so that it's on before the loop
save it.
compile ICE2m.c at starting address 0x8001A000
rename main.exe to ICE2.exe
replace the existing ICE2.exe in the game ISO with your new version
Make another ISO with your new file
Now test it out to see if you did it right. You should be able to use QUICK from the menu while playing ICE WOMAN.
Just about to try this out on real hardware. May I ask why you've omitted the intro from the upload? Do you have a link to the full iso?
If your trying it out on real hardware, use the hardware mode 320x240. 640x480 don't work cause of the GPU slowdown problem. I've read somewhere that it's solvable, but I haven't given all my time and effort into fixing it yet. Honestly, I'm not sure if I can actually solve it, but I know it has something to do with the wrong framebuffer getting updated/ leaving the other frame buffer with the same image data.
As for your question about the intro, yes, ive taken out the intro for file size purposes. The ISO is 80 Megs with the intro intact. Also, the no intro version is better to work with if your recompiling source code, no need for stripISO or MakeCTI Mode2 Form2 XA files. Any iso making program should work really. But if you must have the intro, I'll upload a version for use. It may take a while though.
As for your question about the intro, yes, ive taken out the intro for file size purposes. The ISO is 80 Megs with the intro intact. Also, the no intro version is better to work with if your recompiling source code, no need for stripISO or MakeCTI Mode2 Form2 XA files. Any iso making program should work really. But if you must have the intro, I'll upload a version for use. It may take a while though.
Not to worry, I was just curious. I tried it on real hardware this afternoon at 320x240 as per the menu instruction, it's pretty slick .
You don't need stripISO or MakeCTI if you have Pixel's cd-tool. It can compile an ISO all right, even with XA sectors properly encoded.
Also, may I ask you why you used so many exes? You should move all the stuff to overlays, they will improve loading performances quite a lot. Not to mention you could be using a package to store all the data; this will avoid all the search & seek going on with libcd.
Also, may I ask you why you used so many exes? You should move all the stuff to overlays, they will improve loading performances quite a lot. Not to mention you could be using a package to store all the data; this will avoid all the search & seek going on with libcd.
Well, i use to have one big exe but it was getting too big for memory to hold, so I decided to split it up into separate exes so I could program each boss/stage individually. I could fit more data since each boss/stage is a totally independent exe. I know i could use a BIN with sectors, i suppose, but I use a lot of libcd/libds file searching functions.
As for the data, your right, packaging them together into one BIN does increase loading time, but it doesn't help development time. I made it a point to myself not to BIN all the files together until im done with everything.
As for the data, your right, packaging them together into one BIN does increase loading time, but it doesn't help development time. I made it a point to myself not to BIN all the files together until im done with everything.
-
Shadow Verified
- Admin / PSXDEV
- Posts: 2670
- Joined: Dec 31, 2012
- PlayStation Model: H2000/5502
- Discord: Shadow^PSXDEV
I noticed that developers use multiple separate exe's also, such as Tombi (Tomba). There is nothing wrong with it. You just should then use packages to store the data like Gemini said. There is also a way or trick to actually store your data on the CD-ROM to stop the laser head from going crazy, backwards and forwards to seek. I don't know exactly how to build a package and select the tracks/sectors you can write too, but im sure Gemini would be up to explaining how. Also, your game does not have auto or even manual region selection in the exe's! You should add it into the boot sequence before anything gets drawn. On my TV, since it is forced to NTSC, my V-HOLD is off and I can't adjust it on it so I get a flickering image which I cant play on.
Development Console: SCPH-5502 with 8MB RAM, MM3 Modchip, PAL 60 Colour Modification (for NTSC), PSIO Switch Board, DB-9 breakout headers for both RGB and Serial output and an Xplorer with CAETLA 0.34.
PlayStation Development PC: Windows 98 SE, Pentium 3 at 400MHz, 128MB SDRAM, DTL-H2000, DTL-H2010, DTL-H201A, DTL-S2020 (with 4GB SCSI-2 HDD), 21" Sony G420, CD-R burner, 3.25" and 5.25" Floppy Diskette Drives, ZIP 100 Diskette Drive and an IBM Model M keyboard.
PlayStation Development PC: Windows 98 SE, Pentium 3 at 400MHz, 128MB SDRAM, DTL-H2000, DTL-H2010, DTL-H201A, DTL-S2020 (with 4GB SCSI-2 HDD), 21" Sony G420, CD-R burner, 3.25" and 5.25" Floppy Diskette Drives, ZIP 100 Diskette Drive and an IBM Model M keyboard.
Overlays were crete with the same idea, but instead of including libraries and other stuff you'd need from the SDK they only include the bare minimum code used exclusively by the child process. PSY-Q samples include several programs to show how they work. Basically, you're gonna compile an object with an additional parameter to tell the linker to which group it belongs to. The extra command to do so in the makefile is:isufje wrote:Well, i use to have one big exe but it was getting too big for memory to hold, so I decided to split it up into separate exes so I could program each boss/stage individually. I could fit more data since each boss/stage is a totally independent exe.
Code: Select all
CCOOPTIONS = -O$(OPTIMIZE) -G0 -c -DOVERLAY -D$(RELMODE)
MENU_SRC = menu.c equip.c ability.c orb.c keyitem.c config.c diary.c bestiary.c maps.c glossary.c debug.c shop.c list.c
MENU_OBJ = $(patsubst %.c, $(RELMODE)/%.obm, ${MENU_SRC})
# menu
$(RELMODE)/%.obm : menu/%.c
$(CC) $(CCOOPTIONS) -Wa,smenu $< -o $@
Code: Select all
menu group over(title),file("overlays\MENU.BIN")
include menu.obm
include equip.obm
include ability.obm
include orb.obm
include keyitem.obm
include config.obm
include diary.obm
include bestiary.obm
include maps.obm
include glossary.obm
include shop.obm
include debug.obm
include list.obm
Code: Select all
section .data
title group
xdef LoadAddress
section .rdata ; define as read-only data.
LoadAddress dw group(title)
If that is misleading or not clear enough, you can find an actual example from my engine here.
In my engine I've been using packages almost from the beginning and I can assure you it doesn't slow down development at all, but quite the contrary. In order to handle packages the correct way, you'd want to have a header in the package with sector addresses, a size parameter, and maybe a name table in the first sector. From there, all you gotta do is using CdSearchFile to retrieve the absolute address of the package on disk and add it to the local file pointers in the header. Here you can find my own implementation of that.I know i could use a BIN with sectors, i suppose, but I use a lot of libcd/libds file searching functions.
As for the data, your right, packaging them together into one BIN does increase loading time, but it doesn't help development time. I made it a point to myself not to BIN all the files together until im done with everything.
[youtube]http://www.youtube.com/watch?v=UnDwNzyU30I[/youtube]
DownloadGame: http://forum.rockmanpm.com/index.php?topic=6560.0
Any feedback would be nice.
Cool! That's the first PSX homebrew game with 3D polygon sprites that I've ever seen.
Unfortunately it's running rather slow on my old PC, even in 320pixel mode it seems to require a lot of unneccessary rendering. For example, in the "CAUSE YOU OBVIOUSLY SUCK!!!" screen, it's clearing the background thrice. From no$psx vram viewer:I don't know if that's causing lag on real hardware, maybe it's only causing problems with emulators on older PCs.
The issue is that you can have only ONE frame buffer at that resolution (guess you've meanwhile figured out that, too. Or, if you haven't already been aware of it: check no$psx vram viewer to see how your vram is organized).
I am not too sure if it would be possible to use 640x480 pixels for that game on real hardware. It would work if the PSX could do the whole rendering during Vblank (but I'd assume that the GPU isn't fast enough for that). Or render the image (from top down) in ahead of the cathode ray beam (maybe the GPU is fast enough for that). Or update only small VRAM snippets (eg. only sprites, would be a problem if the whole BG color changes).
And I came across a problem with my BIOS clone (ie. in no$psx, it's working only with the original Sony BIOS). The problem is that you are using this BIOS patch/hack (located at at 80010B68h and 8001B85Ch in the ISO from 20 Dec 2013):Which is adding one more hack to the list of known patches http://nocash.emubase.de/psx-spx.htm#biospatches - I was hoping that people would stick with the existing patches, trying to support that patches is bit like fighting windmills.
Anyways, I was wondering why you are doing that? Is it something to patch improper values in .EXE headers manually? And is it your own invention, or is something implemented in official libraries? I've never seen that patch in retail games yet though.
Oh, and in the menues: It would be nice if it would also accept the X-button, alternately to pressing the START-button!
Unfortunately it's running rather slow on my old PC, even in 320pixel mode it seems to require a lot of unneccessary rendering. For example, in the "CAUSE YOU OBVIOUSLY SUCK!!!" screen, it's clearing the background thrice. From no$psx vram viewer:
Code: Select all
FillVram320x240 ;fill buffer by color black
Texpage
Rect656x496 ;draw monochrome black texture
Texpage
Rect640x480Semi ;draw monochrome semitransparent rectangle
Ah, I was already wondering how you got it working at 640x480 pixels, looked like magicisufje wrote:If your trying it out on real hardware, use the hardware mode 320x240. 640x480 don't work cause of the GPU slowdown problem. I've read somewhere that it's solvable, but I haven't given all my time and effort into fixing it yet. Honestly, I'm not sure if I can actually solve it, but I know it has something to do with the wrong framebuffer getting updated/ leaving the other frame buffer with the same image data.
The issue is that you can have only ONE frame buffer at that resolution (guess you've meanwhile figured out that, too. Or, if you haven't already been aware of it: check no$psx vram viewer to see how your vram is organized).
I am not too sure if it would be possible to use 640x480 pixels for that game on real hardware. It would work if the PSX could do the whole rendering during Vblank (but I'd assume that the GPU isn't fast enough for that). Or render the image (from top down) in ahead of the cathode ray beam (maybe the GPU is fast enough for that). Or update only small VRAM snippets (eg. only sprites, would be a problem if the whole BG color changes).
And I came across a problem with my BIOS clone (ie. in no$psx, it's working only with the original Sony BIOS). The problem is that you are using this BIOS patch/hack (located at at 80010B68h and 8001B85Ch in the ISO from 20 Dec 2013):
Code: Select all
8C030474 mov r3,[200h+(9Dh*4)] ;\get ptr to A(9Dh) GetConf (done so,
00000000 nop ;/as there's no "GetA0Table" funtion)
94620000 movh r2,[r3+0h] ;lui msw ;\
84630004 movhs r3,[r3+4h] ;lw lsw+8 ; extract ptr to "boot_cnf_values"
00021400 shl r2,10h ;msw*10000h ; (from first 2 opcodes of GetConf)
2442FFF8 sub r2,8h ;undo +8 ;
00431021 add r2,r3 ;lsw ;/
AC450000 mov [r2+0h],r5 ;num_TCB ;\set num_EvCB,num_TCB,stacktop
AC440004 mov [r2+4h],r4 ;num_EvCB ; (unlike A(9Ch) SetConf, without
03E00008 ret ; actually reallocting anything)
AC460008 +mov [r2+8h],r6 ;stacktop ;/
Anyways, I was wondering why you are doing that? Is it something to patch improper values in .EXE headers manually? And is it your own invention, or is something implemented in official libraries? I've never seen that patch in retail games yet though.
For auto selection, best would be using the CDROM region test command (19h,22h), if it does return INT3("for Europe") then you can be sure that the user is having a PAL console (and thus expect that it's used with a PAL TV Set). For anything other regions I would default to NTSC (including multi-region Yaroze consoles). Normally, any semi-modern PAL TVs should be able display 60Hz NTSC pictures anyways (bigger issue is that unmodded PSX consoles are producing incorrect colors if the TV region is wrong).Shadow wrote:your game does not have auto or even manual region selection in the exe's! You should add it into the boot sequence before anything gets drawn. On my TV, since it is forced to NTSC, my V-HOLD is off and I can't adjust it on it so I get a flickering image which I cant play on.
Oh, and in the menues: It would be nice if it would also accept the X-button, alternately to pressing the START-button!
Who is online
Users browsing this forum: No registered users and 2 guests