[Question] Screen scale?

Graphic based area of development (Graphics Processing Unit), including the Geometry Transform Engine (GTE), TIM, STR (MDEC), etc.
Post Reply
User avatar
NITROYUASH
Verified
Serious PSXDEV User
Serious PSXDEV User
Posts: 124
Joined: Jan 07, 2018
I am a: Game Designer
PlayStation Model: SCPH-5502
Location: Russian Federation
Contact:

[Question] Screen scale?

Post by NITROYUASH » August 23rd, 2019, 11:14 pm

Hi PSXDEV.

Using DRAWENV draw and PutDrawEnv(&draw), i can modify the screen size in the while loop dynamically.

Here is the visualisation of how it's works right now:
► Show Spoiler
Almost working.
I'm curious, is it possible to scale the screen dynamically for show full resolution in smaller in-game screen?

Thanks for the answer!

User avatar
MihaiGamerXD
Active PSXDEV User
Active PSXDEV User
Posts: 38
Joined: Mar 09, 2019
I am a: Programmer
PlayStation Model: SCPH-1001

Post by MihaiGamerXD » August 24th, 2019, 3:50 am

Mm... I don't think it's possible, I didn't tried out.

User avatar
NITROYUASH
Verified
Serious PSXDEV User
Serious PSXDEV User
Posts: 124
Joined: Jan 07, 2018
I am a: Game Designer
PlayStation Model: SCPH-5502
Location: Russian Federation
Contact:

Post by NITROYUASH » August 24th, 2019, 6:56 am


User avatar
MihaiGamerXD
Active PSXDEV User
Active PSXDEV User
Posts: 38
Joined: Mar 09, 2019
I am a: Programmer
PlayStation Model: SCPH-1001

Post by MihaiGamerXD » August 24th, 2019, 7:30 am

I can see. But your second screenshot is the same as the video! Isn't it?

EDIT: Also, give me your source code so I can help you.

User avatar
NITROYUASH
Verified
Serious PSXDEV User
Serious PSXDEV User
Posts: 124
Joined: Jan 07, 2018
I am a: Game Designer
PlayStation Model: SCPH-5502
Location: Russian Federation
Contact:

Post by NITROYUASH » August 26th, 2019, 9:04 pm

I managed to get PutDrawEnv to work with GS stuff. Still curious about the screen scale.
Here is the code.

EDIT: Fixed the Display() code

Code: Select all

extern DRAWENV GsDRAWENV;

void startup_init() {

	// . . .

	draw[0] = GsDRAWENV;
	draw[0].clip.x = 0; draw[0].clip.y = 0;
	draw[0].clip.w = SCREENXRES; draw[0].clip.h = SCREENYRES;
	draw[0].ofs[0] = draw[0].clip.x;
	draw[0].ofs[1] = draw[0].clip.y;

	draw[1] = GsDRAWENV;
	draw[1].clip.x = 0; draw[1].clip.y = SCREENYRES;
	draw[1].clip.w = SCREENXRES; draw[1].clip.h = SCREENYRES;
	draw[1].ofs[0] = draw[1].clip.x;
	draw[1].ofs[1] = draw[1].clip.y;

	// . . .

}

Code: Select all

void game_scene() {
	
	// . . .

	while (1) {
		//PrepDisp();

		//PrepDisp
		ActiveBuffer = GsGetActiveBuff();
		GsSetWorkBase((PACKET*)GPUPacketArea[ActiveBuffer]);
		GsClearOt(0, 0, &myOT[ActiveBuffer]);
		gte_myPrimPtr = &gte_myPrims[ActiveBuffer][0];



		SetPad(PORT1,PORT2);

		if (dbg.active) {

			// . . .

			// Sorry for that FntPrint """code""", i made it only for simple tests :)
			FntPrint("%sGAME SETTINGS\n", (dbg.cur_pos == 2+dbg.sub_list[0]+dbg.sub_list[1] ? "->" : "  "));
			if (dbg.sub[2] == true) {
				if (dbg.cur_pos == 3+dbg.sub_list[0]+dbg.sub_list[1]) {
					if (Button_Press(0, D_LEFT, PD_LEFT, HOLD)) {
						draw[0].clip.x --; draw[1].clip.x --; }
					if (Button_Press(0, D_RIGHT, PD_RIGHT, HOLD)) {
						draw[0].clip.x ++; draw[1].clip.x ++; }
				} else if (dbg.cur_pos == 4+dbg.sub_list[0]+dbg.sub_list[1]) {
					if (Button_Press(0, D_LEFT, PD_LEFT, HOLD)) {
						draw[0].clip.y --; draw[1].clip.y --; }
					if (Button_Press(0, D_RIGHT, PD_RIGHT, HOLD)) {
						draw[0].clip.y ++; draw[1].clip.y ++; }
				} else if (dbg.cur_pos == 5+dbg.sub_list[0]+dbg.sub_list[1]) {
					if (Button_Press(0, D_LEFT, PD_LEFT, HOLD)) {
						draw[0].clip.w --; draw[1].clip.w --; }
					if (Button_Press(0, D_RIGHT, PD_RIGHT, HOLD)) {
						draw[0].clip.w ++; draw[1].clip.w ++; }
				} else if (dbg.cur_pos == 6+dbg.sub_list[0]+dbg.sub_list[1]) {
					if (Button_Press(0, D_LEFT, PD_LEFT, HOLD)) {
						draw[0].clip.h --; draw[1].clip.h --; }
					if (Button_Press(0, D_RIGHT, PD_RIGHT, HOLD)) {
						draw[0].clip.h ++; draw[1].clip.h ++; }
				} else if (dbg.cur_pos == 7+dbg.sub_list[0]+dbg.sub_list[1]) {
					if (Button_Press(0, D_LEFT, PD_LEFT, HOLD)) {
						draw[0].ofs[0] --; draw[1].ofs[0] --; }
					if (Button_Press(0, D_RIGHT, PD_RIGHT, HOLD)) {
						draw[0].ofs[0] ++; draw[1].ofs[0] ++; }
				} else if (dbg.cur_pos == 8+dbg.sub_list[0]+dbg.sub_list[1]) {
					if (Button_Press(0, D_LEFT, PD_LEFT, HOLD)) {
						draw[0].ofs[1] --; draw[1].ofs[1] --; }
					if (Button_Press(0, D_RIGHT, PD_RIGHT, HOLD)) {
						draw[0].ofs[1] ++; draw[1].ofs[1] ++; }
				}

				FntPrint("%s Screen X: %d\n",
					(dbg.cur_pos == 3+dbg.sub_list[0]+dbg.sub_list[1] ? "->" : "  "),
					draw[0].clip.x );
				FntPrint("%s Screen Y: %d\n",
					(dbg.cur_pos == 4+dbg.sub_list[0]+dbg.sub_list[1] ? "->" : "  "),
					draw[0].clip.y );
				FntPrint("%s Screen W: %d\n",
					(dbg.cur_pos == 5+dbg.sub_list[0]+dbg.sub_list[1] ? "->" : "  "),
					draw[0].clip.w );
				FntPrint("%s Screen H: %d\n",
					(dbg.cur_pos == 6+dbg.sub_list[0]+dbg.sub_list[1] ? "->" : "  "),
					draw[0].clip.h );
				FntPrint("%s Offset 0: %d\n",
					(dbg.cur_pos == 7+dbg.sub_list[0]+dbg.sub_list[1] ? "->" : "  "),
					draw[0].ofs[0] );
				FntPrint("%s Offset 1: %d\n",
					(dbg.cur_pos == 8+dbg.sub_list[0]+dbg.sub_list[1] ? "->" : "  "),
					draw[0].ofs[1] );

			}

			// . . .
		}

		// . . . (here was the SORT code)

		//Display();



		//Display
		DrawSync(0);						
		VSync(0);							

		GsSwapDispBuff();
		GsSortClear(g_iGS_R, g_iGS_G, g_iGS_B, &myOT[ActiveBuffer]);		// 

		ActiveDisp ^= 1;					// Swap active draw display
		PutDrawEnv(&draw[ActiveDisp]);		// Put active draw display

		GsDrawOt(&myOT[ActiveBuffer]);		
		FntFlush(-1);						
	}

}

User avatar
NITROYUASH
Verified
Serious PSXDEV User
Serious PSXDEV User
Posts: 124
Joined: Jan 07, 2018
I am a: Game Designer
PlayStation Model: SCPH-5502
Location: Russian Federation
Contact:

Post by NITROYUASH » August 27th, 2019, 8:14 am

Hmm. I found something about how they're do that.
Look at this images.
► Show Spoiler
As you can see, on the second image, the screenshot of the game appearing on the VRAM memory. So, they're not scale the game display, but they're made the screenshot, put it to VRAM and then sort it (?)

Okay, i have only one question.
How to transfer the display screen to VRAM?

User avatar
LameGuy64
Verified
Psy-Q Enthusiast
Psy-Q Enthusiast
Posts: 388
Joined: Apr 10, 2013
I am a: Hobbyist Game Developer
Motto: Commercial or not, play it!
PlayStation Model: H2000/7000
Location: Philippines
Contact:

Post by LameGuy64 » August 27th, 2019, 7:37 pm

The hardware cannot really scale the size of the picture shown on the screen. The closest you can get to accomplish such a thing is by a combination of choosing one of five supported horizontal screen resolutions (256, 320, 384, 512, 640) and one of two vertical screen resolutions (240 and 480 for NTSC, 256 and 512 for PAL), then setting coordinates in DISPENV.screen to adjust the picture position and amount of pixels shown on screen. I haven't tried it personally but it should work in theory.
Please don't forget to include my name if you share my work around. Credit where it is due.

Dev. Console: SCPH-7000 with SCPH-7501 ROM, MM3, PAL color fix, Direct AV ports, DB-9 port for Serial I/O, and a Xplorer FX with Caetla 0.35.

DTL-H2000 PC: Dell Optiplex GX110, Windows 98SE & Windows XP, Pentium III 933MHz, 384MB SDRAM, ATI Radeon 7000 VE 64MB, Soundblaster Audigy, 40GB Seagate HDD, Hitachi Lite-on CD-RW Drive, ZIP 250 and 3.5" Floppy.

User avatar
NITROYUASH
Verified
Serious PSXDEV User
Serious PSXDEV User
Posts: 124
Joined: Jan 07, 2018
I am a: Game Designer
PlayStation Model: SCPH-5502
Location: Russian Federation
Contact:

Post by NITROYUASH » August 27th, 2019, 8:57 pm

I tried to modify the DISPENV parameters, of course. It didn't work so well.
So, the only way to do that, is making the screenshot of the display to VRAM. But still, how they're do that? I have 2 theories about that. They're get the every pixel color from the screen or they're just copy the display RECT? By the way, is it possible to get the pixel color from the display?

User avatar
Shadow
Verified
Admin / PSXDEV
Admin / PSXDEV
Posts: 2670
Joined: Dec 31, 2012
PlayStation Model: H2000/5502
Discord: Shadow^PSXDEV

Post by Shadow » August 29th, 2019, 8:11 am

NITROYUASH wrote: August 27th, 2019, 8:57 pm I tried to modify the DISPENV parameters, of course. It didn't work so well.
So, the only way to do that, is making the screenshot of the display to VRAM. But still, how they're do that?
StoreImage and LoadImage.
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.

User avatar
LameGuy64
Verified
Psy-Q Enthusiast
Psy-Q Enthusiast
Posts: 388
Joined: Apr 10, 2013
I am a: Hobbyist Game Developer
Motto: Commercial or not, play it!
PlayStation Model: H2000/7000
Location: Philippines
Contact:

Post by LameGuy64 » August 29th, 2019, 12:33 pm

The most efficient method I could come up with is to draw to a off-screen area using a DR_AREA primitive, then switch to your main drawing area with DR_AREA then draw the off-screen one as a 16-bit texture. The off-screen draw area should only be up to 256x256 as that's the maximum addressable texture size per page, unless you span the drawing across multiple primitives.

I do not recommend doing screen scaling on the PS1 unless you want poor image quality, as scaling without any kind of filtering will look like a shimmery mess.
Please don't forget to include my name if you share my work around. Credit where it is due.

Dev. Console: SCPH-7000 with SCPH-7501 ROM, MM3, PAL color fix, Direct AV ports, DB-9 port for Serial I/O, and a Xplorer FX with Caetla 0.35.

DTL-H2000 PC: Dell Optiplex GX110, Windows 98SE & Windows XP, Pentium III 933MHz, 384MB SDRAM, ATI Radeon 7000 VE 64MB, Soundblaster Audigy, 40GB Seagate HDD, Hitachi Lite-on CD-RW Drive, ZIP 250 and 3.5" Floppy.

User avatar
NITROYUASH
Verified
Serious PSXDEV User
Serious PSXDEV User
Posts: 124
Joined: Jan 07, 2018
I am a: Game Designer
PlayStation Model: SCPH-5502
Location: Russian Federation
Contact:

Post by NITROYUASH » August 30th, 2019, 5:11 am

Shadow wrote: August 29th, 2019, 8:11 am
NITROYUASH wrote: August 27th, 2019, 8:57 pm I tried to modify the DISPENV parameters, of course. It didn't work so well.
So, the only way to do that, is making the screenshot of the display to VRAM. But still, how they're do that?
StoreImage and LoadImage.
It's working! No idea why i made it to work only after your message, because i tried to do something with StoreImage before. Maybe because i wasn't sure if this would work.

User avatar
NITROYUASH
Verified
Serious PSXDEV User
Serious PSXDEV User
Posts: 124
Joined: Jan 07, 2018
I am a: Game Designer
PlayStation Model: SCPH-5502
Location: Russian Federation
Contact:

Post by NITROYUASH » October 6th, 2019, 8:23 pm

Don't want to make another theme so i decided to ask here.
Can i change the Black Flag for a prepared data for VRAM (StoreImage/LoadImage method)?
I mean, this flag can be turned off for TIM's:
Image

User avatar
LameGuy64
Verified
Psy-Q Enthusiast
Psy-Q Enthusiast
Posts: 388
Joined: Apr 10, 2013
I am a: Hobbyist Game Developer
Motto: Commercial or not, play it!
PlayStation Model: H2000/7000
Location: Philippines
Contact:

Post by LameGuy64 » October 7th, 2019, 8:03 pm

LoadImage/StoreImage always retains and overwrites the STP bits of pixels being read or written. 16-bit TIMs have STP bits in all pixels while 8-bit and 4-bit TIMs have the STP bits in the CLUT pixels instead.

True black (0, 0, 0) is normally treated as the transparent color when drawn using textured sprite or polygon primitives. But if the STP bit is set, true black pixels will be drawn instead of being fully transparent.
Please don't forget to include my name if you share my work around. Credit where it is due.

Dev. Console: SCPH-7000 with SCPH-7501 ROM, MM3, PAL color fix, Direct AV ports, DB-9 port for Serial I/O, and a Xplorer FX with Caetla 0.35.

DTL-H2000 PC: Dell Optiplex GX110, Windows 98SE & Windows XP, Pentium III 933MHz, 384MB SDRAM, ATI Radeon 7000 VE 64MB, Soundblaster Audigy, 40GB Seagate HDD, Hitachi Lite-on CD-RW Drive, ZIP 250 and 3.5" Floppy.

User avatar
MrQuetch
Active PSXDEV User
Active PSXDEV User
Posts: 42
Joined: Apr 01, 2018
I am a: Programmer and artist.
Motto: You can accomplish anything.
Location: United States

Post by MrQuetch » February 21st, 2020, 9:49 am

LameGuy64 wrote: October 7th, 2019, 8:03 pm LoadImage/StoreImage always retains and overwrites the STP bits of pixels being read or written. 16-bit TIMs have STP bits in all pixels while 8-bit and 4-bit TIMs have the STP bits in the CLUT pixels instead.

True black (0, 0, 0) is normally treated as the transparent color when drawn using textured sprite or polygon primitives. But if the STP bit is set, true black pixels will be drawn instead of being fully transparent.
Is there an exact function for setting the STP bits so we can choose when we want true black (0, 0, 0) to be transparent or not? Thanks for the information, by the way - I was curious as to how this worked.

Post Reply

Who is online

Users browsing this forum: No registered users and 5 guests