RaVeN-05 wrote on 2025-08-28, 10:14:

Can wait months.
Icr2 and CGL is more priority.
As for my bugs reports, maybe it's good idea to have something like github? So reports will be not drowned down like in forum, for future reading/fixing?

One final build:
https://nirvtek.com/downloads/RReady.Alpha.20250828.002.7z
MD5: 222b748f133c0cbab6ecb5f86ef9bef7

- vQuake 2 particles. The perspective correction for particles is disabled for vHexen 2 and vQuake 1. These two don't appear to need it in both vanilla and antialiased modes.
- The keyboard code for ICR2 should be perfect now.

RaVeN-05 wrote on 2025-08-28, 11:09:

Popular games and exclusive games (stick to their api / vcard) is more priority as I think, and thinks it's logical, like glrage […]
Show full quote

Popular games and exclusive games (stick to their api / vcard) is more priority as I think, and thinks it's logical, like glrage for supporting 3 of their exclusive 3d rage games. Or tied apis in priority (tied I call where particular game can have many api renderers but none of them got wrappers nor emulators).

Best looking in defined api games is could be counted as in priority.

For example mech warrior 2 exist on many api renderers but only SGL api (PowerVR) is best looking, since have more graphical effects than rest of their apis.

Hexen2 and majority of dos games is better on RReady.
Especially soda, Rebmoon, Icr2, flawless now.
P. S. Dos even more better I think because dosbox provider more stable execution than old win32 apps on new windows oses.

You're right. It's just that I don't like sitting on fixes. Most of the fixes are for games that aren't very popular so I guess it can wait.

Will try to place all the bugs i found on sourceforge tickets , so to easy found and not lost them.

Streamed: Tomb Raider
found bugs:
after quiting game , dosbox have garbage font.
i once get lost of character control for several seconds, like buffer with input is slowly sends commands to game , so i can't control character properly , maybe its dosbox keyboard handling shared problem?
https://www.twitch.tv/videos/2551851697?t=00h29m44s

FrameGeneration should be turned off for this game, its can boost from 30-fps to 60 fps, but there will be HOM deffects, like shadow under Lara is HOM and menus their backgrounds not cleared

Usabiliy of RReady UI:
there is chance you can quickly press "Launch" button two or more times, which will run more than one dosobox instances, later even will report errors , of they cant copy files.
possible fix - make "Launch" button to self-lock for second , grayed for second. Also there is not necessary to copy entire dosbox files to some location, i guess it can run out of rready folder directly?

so also duplicated to sourceforge tickets , so now its will be not missed.
again lowest ever priority for that.

RaVeN-05 wrote on 2025-08-28, 13:15:

Will try to place all the bugs i found on sourceforge tickets , so to easy found and not lost them. […]
Show full quote

Will try to place all the bugs i found on sourceforge tickets , so to easy found and not lost them.

Streamed: Tomb Raider
found bugs:
after quiting game , dosbox have garbage font.
i once get lost of character control for several seconds, like buffer with input is slowly sends commands to game , so i can't control character properly , maybe its dosbox keyboard handling shared problem?
https://www.twitch.tv/videos/2551851697?t=00h29m44s

FrameGeneration should be turned off for this game, its can boost from 30-fps to 60 fps, but there will be HOM deffects, like shadow under Lara is HOM and menus their backgrounds not cleared

Usabiliy of RReady UI:
there is chance you can quickly press "Launch" button two or more times, which will run more than one dosobox instances, later even will report errors , of they cant copy files.
possible fix - make "Launch" button to self-lock for second , grayed for second. Also there is not necessary to copy entire dosbox files to some location, i guess it can run out of rready folder directly?

so also duplicated to sourceforge tickets , so now its will be not missed.
again lowest ever priority for that.

The console corruption occurs on real hardware as well with both v2k and v1k.

https://nirvtek.com/downloads/RReady.Alpha.20250829.002.7z
MD5: 4ebff76757f2934e50eee77d99224871
1) Disable the Launch button for a few seconds
2) Compare the files being copied to see if they're the same, if they are the file isn't copied. The app will take a slightly longer time to launch since each and every file is compared.
3) should hopefully correct input lag in test builds with the new keyboard code.

Osterreichring, North Point and Mosport (including 1967):
https://youtu.be/bU00PI0EwQo

https://nirvtek.com/downloads/RReady.Alpha.20250829.003.7z
MD5: 4a7633da2497e010f253cc690be00451

1) Disable the Launch button for a few seconds after launch. This release all the fixes of the previous builds and corrects glitchiness with disabling the launch button when pressing [ENTER] or using the arrow keys to navigate the apps list
2) When launching compare the files being copied to see if they're the same, if they are the file isn't copied. The app will take a slightly longer time to launch since each and every file is compared, but SSD wear should be minimal.
3) This release should hopefully correct input lag seen in test builds:

@TedMeat has posted a video of force feedback and Rendition support in ICR2:
https://youtu.be/-0U8wrEh_YI?si=eKWTQkdI6MaNCdnv

[EDIT]ICR2 Monza, Montreal (N1/ICR2) and Monterrey:
https://youtu.be/203zAU4eLI0

Whiplash:
menu blinking in whiplash
select option have black outline in main menu
inconsistent fps in gameplay varies from 30 to 70
from time to time there single frame where most polygons missed or painted with wrong colors.
in game play (at racaway) there is right most and bottom most edges of the screen have mess lines

RaVeN-05 wrote on 2025-08-31, 09:28:

Whiplash: menu blinking in whiplash select option have black outline in main menu inconsistent fps in gameplay varies from 30 to […]
Show full quote

Whiplash:
menu blinking in whiplash
select option have black outline in main menu
inconsistent fps in gameplay varies from 30 to 70
from time to time there single frame where most polygons missed or painted with wrong colors.
in game play (at racaway) there is right most and bottom most edges of the screen have mess lines

Don't forget to file those TPS reports!

Does anyone know if the Radeon R7 240 has a problem with geometry shaders? I tried all the vQuake engine games and the QSpan rendering is broken horribly. In SODA offroad the line renderer, which also uses a geometry shader, works fine.

This suggests to me that somehow my GS are non-compliant, but they do work on nvidia and intel HD.

[EDIT]
https://youtu.be/Tt-Of0y3tAI
Desert Winds, Edmonton and Heartlands Park are now Rendition Ready as are Imola, Lime Rock, Indianapolis Raceway and Kyalami:
https://youtu.be/1L_81lnmvis

Whiplash demos with minor bug fixes: https://youtu.be/zkHUn0T17IE
[/EDIT]

Perhaps you can find some useful information here: https://stackoverflow.com/questions/21623238/ … rk-on-amd-cards

Makus wrote on Yesterday, 10:17:

Perhaps you can find some useful information here: https://stackoverflow.com/questions/21623238/ … rk-on-amd-cards

Thanks for that, but the geometry shader in that post has an obvious bug. Mine may be bugged, but I can't figure out what it is.

In the case of the shader there there's an assignment a = (b+=10) (something like this). It should be a =(b+10). For += to work the line would have to start with b +=.

My shaders look like this:

Vertex

1#version 150 compatibility
2uniform float texWidth;
3uniform float texHeight;
4
5uniform vec4 baseOffset;
6uniform vec4 colourIn;
7
8
9in vec4 tcIn;
10in float spanLength;
11
12
13out vec4 pos;
14out vec4 colour;
15out vec2 size;
16//flat out mat4 mvp;
17out float X1, X2, Y1, Y2, Z1, Z2;
18out float length;
19out float z1, z2;
20
21
22
23void main()
24{
25
26	size = vec2(1.0, 1.0);
27
28
29	Z1 = tcIn.w/-2048.0;
30	Z2 = Z1 + spanLength * baseOffset.w/-2048.0;
31
32
33
34	float xScale = baseOffset.x;
35	float yScale = baseOffset.y;
36
37
38	z1 = tcIn.z/16777215.0;///65536.0/128.0;
39	z2 = (tcIn.z + baseOffset.z * spanLength)/16777215.0;///65536.0/128.0;
40
41	X1 = tcIn.x/65536.0/texWidth;
42
43	X2 = (tcIn.x + spanLength * xScale)/65536.0/texWidth;
44
45	Y1 = tcIn.y/65536.0/texHeight;	
46	Y2 = (tcIn.y + spanLength * yScale)/65536.0/texHeight;
47
48
49	length  = spanLength;
50
51	colour = colourIn;//gl_Color;
52	gl_Position = pos = vec4(gl_Vertex.y, gl_Vertex.x, 0/*-abs(gl_Vertex.z)*/, gl_Vertex.w);   
53	//mvp = gl_ModelViewProjectionMatrix;
54
55}

Geometry:

1#version 150 compatibility
2layout (points) in;
3layout (triangle_strip, max_vertices = 4) out;
4
5//flat in mat4 mvp[];
6in vec2 size[];
7in vec4 colour[];
8in float X1[], X2[], Y1[], Y2[], Z1[], Z2[];
9in float length[];
10in float z1[], z2[];
11
12out vec4 colourOut;
13out vec2 texCoord;
14out float Z;
15//out float l;
16
17void main() {
18
19	vec2 tc1 = vec2(X1[0], Y1[0]);
20	vec2 tc2 = vec2(X2[0], Y2[0]);
21
22
23	vec4 point0 = gl_in[0].gl_Position + vec4(0.0, 0.0, Z1[0], 0.0);
24	vec4 point1 = gl_in[0].gl_Position + vec4( length[0], 0.0, Z2[0], 0.0);
25
26    gl_Position = gl_ModelViewProjectionMatrix * point0;// - normal;//vec4(-sx, -sy, 0.0, 0.0); 
27	texCoord = tc1;
28	colourOut = colour[0];
29	Z = z1[0];
30	//l  = 0.0;
31    EmitVertex();	
32
33    gl_Position = gl_ModelViewProjectionMatrix * point1;// +vec4(size[0].x, 0.0, 0.0, 0.0));
34	texCoord = tc2;
35	colourOut = colour[0];
36	Z = z2[0];
37	//l = 1.0;
38    EmitVertex();
39
40    gl_Position = gl_ModelViewProjectionMatrix * (point0 + vec4( 0.0, size[0].y, 0.0, 0.0));
41	texCoord = tc1;
42	colourOut = colour[0];
43	Z = z1[0];
44	//l = 0.0;
45    EmitVertex();
46
47    gl_Position = gl_ModelViewProjectionMatrix * (point1 + vec4(size[0].x, size[0].y, 0.0, 0.0));
48	texCoord = tc2;
49	colourOut = colour[0];
50	Z = z2[0];
51	//l = 1.0;
52    EmitVertex();
53
54
55    
56    EndPrimitive();
57}  

Fragment Shader:

1#version 150 compatibility
2uniform float texWidth;
3uniform float texHeight;
4
5uniform sampler2D tex;
6uniform int srcMode;
7uniform bool textureHasAlpha;
8uniform bool eightA;
9uniform bool eightI;
10uniform bool texBgr;
11uniform bool displayPalette;
12uniform sampler2D oldPalette;
13
14
15in vec2 texCoord;
16in vec4 colourOut;
17in float Z;
18in float l;
19
20vec4 GetSrcColour()
21{
22	vec4 colour = texture2D(tex, texCoord.xy/Z);//textureHasAlpha?GetSrcColourWithAlpha():GetSrcColourNoAlpha();
23	
24	if(!textureHasAlpha)
25		colour.a = 1.0;
26
27	if( texBgr)
28		colour = colour.gbar;
29	if(eightA)
30		colour = vec4(1.0, 1.0, 1.0, colour.r);
31	if(eightI)
32		colour = vec4( colour.r, colour.r, colour.r, 1.0);
33
34	//colour.a = eightA?colour.a:textureHasAlpha?colour.a:colourOut.a;
35
36	return colour;
37
38}
39
40vec4 GetColour()
41{
42
43	if(srcMode == 0)
44		return colourOut;
45
46	if(srcMode == 1)	
47		return GetSrcColour();
48
49	if(srcMode == 2 )
50	{
51		vec4 col = GetSrcColour();
52		float a = 1.0 - col.a;
53
54		return  vec4(a, a, a, 1.0) * colourOut + 
55				vec4(col.a, col.a, col.a, 0.0) * col;		
56	}
57	if(srcMode == 3)
58	{
59		return colourOut * GetSrcColour();
60	}

61}
62
63void main()
64{
65	gl_FragColor = GetColour();
66}

Try ChatGPT here.
also commented on recent patreon message.

in short:
AMD vs nVidia, that's all the times like that - nVidia tries to be much as possible to be backward compatible and keep legacy opengl.
AMD is more aggressive here by dropping a lot in favor of speed.

its as simple my exploration trough time. this is why i prefer nVidia , and AMD user in past, i still do have old Radeons, way old like 9X00 series.

As i asked ChatGPT and got very detailed explanations, i simply can short it to one answer - for AMD use 330 core profile

Also from CHatGPT - AMD can fail GS in compiling stage, need somekind of debugger or way opengl will write compiling errors into console.
i recall watching TheCherno OpenGL tutorials , he showed how compiling errors could be printed to console. Well i weak here , i can say what i saw and experienced just.

RaVeN-05 wrote on Yesterday, 15:46:

Try ChatGPT here. also commented on recent patreon message. […]
Show full quote

Try ChatGPT here.
also commented on recent patreon message.

in short:
AMD vs nVidia, that's all the times like that - nVidia tries to be much as possible to be backward compatible and keep legacy opengl.
AMD is more aggressive here by dropping a lot in favor of speed.

its as simple my exploration trough time. this is why i prefer nVidia , and AMD user in past, i still do have old Radeons, way old like 9X00 series.

As i asked ChatGPT and got very detailed explanations, i simply can short it to one answer - for AMD use 330 core profile

Also from CHatGPT - AMD can fail GS in compiling stage, need somekind of debugger or way opengl will write compiling errors into console.
i recall watching TheCherno OpenGL tutorials , he showed how compiling errors could be printed to console. Well i weak here , i can say what i saw and experienced just.

Thanks Raven. I started out with #330 compatibility. I'll try #330 core. The problem is that 330 core doesn't run on Intel HD2000, which while being quite slow, is the minimum.

I'll try printing out the logs. There're no errors, if there were RReady would stop and open the log file. There may be warnings.

probably AMD needs separate approach , like if AMD being detected branch to other GLSL code

RaVeN-05 wrote on Yesterday, 16:10:

probably AMD needs separate approach , like if AMD being detected branch to other GLSL code

No warnings with AMD either. It looks like it's the matrix (modelview-projection) that's the problem. It renders the spans all over the place, just not in the right place.

The line shader, which works just like the qspan shader works fine. It's just the QSpan shader which doesn't work.

Chat GPT found five bugs in the shader. The first three, unused parameters pos and l and using the reserved word length for a parameter have been fixed. The other two 'bugs' are necessary for Rendition to work and shouldn't be fixed, changing pixel format from .gbar to bgra (this is related to the internal format of Rendition textures) and the divide by z (perspective correction) in the fragment shader. This will never cause a divide by zero and the floor it suggests (1e-6) will break the shader. The game will break before this Z becomes 0.

Even with the two actual bugs fixed, it still doesn't work on R7 240 🙁.

The shader appears to be working fine, but one of the vertex attributes doesn't seem to be passed through to the vertex shader:

glVertexAttribPointer(pLib->tcIn, 4, GL_INT, GL_FALSE, sizeof(Span), &spans[i.headerIndex + 1].f.ints.X);

4 32 bit ints forming a 4 dimensional vector per span point. This appears to be garabage inside the shader.

Shaders I heard from TheCherno is sensitive, and even not throwing any warnings or errors could just not work.
There might be some other commands or state changes must be invoked.
Something like: select attrib, select program, activate program, use program.
I don't exactly knew.
The nVidia can be more tolerant for missing opengl commands, while for amd it's need to be specified exactly.

Most of those are set. ChatGPT suggested these:

1// Use a neutral VAO for client arrays, or VAO 0 in compat
2glBindVertexArray(0);
3
4// No VBOs when setting client pointers
5glBindBuffer(GL_ARRAY_BUFFER, 0);
6glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, 0);

Didn't work.
.[edit]
One of the vertex attributes, a float, works just fine. The vec4 does not. I tried splitting it into 4 floats, but it worked on nvidia but not on the Radeon. I *think * the Radeon is doing some sort of scaling or something when passing an int to a float parameter. I even tried passing it as an ivec4 4 component integer vector but once again, only works on nvidia. The parameter which works is a signed short (2 bytes) not a signed int (4 bytes)