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

[isufje]

---

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.

[Administrator]

That is very cool. Did you start making the game this year?

[isufje]

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...

[Administrator]

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.

[isufje]

thanx

[CosmoGuy]

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.

[isufje]

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.

[Administrator]

My gosh. Such terrible loading times

[isufje]

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.

[isufje]

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

[isufje]

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.

[cookie]

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?

[isufje]

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.

[cookie]

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 .

[Gemini]

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.

[isufje]

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.

[Administrator]

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.

[Gemini]

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.

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:

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 $@

Now open your link file (usually *.lk) and add these lines:

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

Finally, you need to create a group attribute, which is usually done by having an assembly file with the following lines:

Code: Select all

 	section	.data
title group
	xdef LoadAddress
	section	.rdata		; define as read-only data.
LoadAddress		dw	group(title)

This will create *.obm (or whatever extension you'd like to use, say *.ob0, *.ob1, etc.) which belong to the "menu" group.

If that is misleading or not clear enough, you can find an actual example from my engine here.

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.

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.

[isufje]

[youtube]http://www.youtube.com/watch?v=UnDwNzyU30I[/youtube]
DownloadGame: http://forum.rockmanpm.com/index.php?topic=6560.0




Any feedback would be nice.

[nocash]

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:

Code: Select all

FillVram320x240     ;fill buffer by color black
Texpage
Rect656x496         ;draw monochrome black texture
Texpage
Rect640x480Semi     ;draw monochrome semitransparent rectangle

I don't know if that's causing lag on real hardware, maybe it's only causing problems with emulators on older PCs.

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.

Ah, I was already wondering how you got it working at 640x480 pixels, looked like magic
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   ;/

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.

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.

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).

Oh, and in the menues: It would be nice if it would also accept the X-button, alternately to pressing the START-button!