Hmm no, these are LFB animations. No triangle commands.

textures are working, for some games, but it looks like it's using textures with minimal lod, they're blocky, and w/o alpha channel?.

maybe it takes the texel at 0,0 for the whole triangle? need to check this further. do you have any ideas about this?
all the stability issues seem fixed now. all the games I tested seem to run fine, albeit a bit slow. once fixed the textures issue, the rendered should be optimized and threaded.
Mame already offloads rendering of scanlines to a thread queue; I commented out the whole thing to make emulation work first, but I think the whole triangle rasterizing may be threaded. Also the scanline renderer may be optimized a bit, I guess.

i have noticed (i don't know what is causing it) that in win95b, 95c and 98se quake 3 looks one way. While on win98fe it looks differently. Although i have a suspicion if emulation works correctly they may look the same. Maybe they are just trying to go to the same place using slightly different methods. Here are pictures made before your todays patch:

and here are made after your todays patch:

btw it is best to use fixed cycles ( as cycles max doesn't leave any resources to 3dfx. )
And lowering cycles when 3dfx is used, and highering cycles when 3dfx is not used.

previously some the textures in some games were not visible cause they had alpha channel applied (cause rgba channels were mixed up). Right now there is a higher chance that texture will be visible cause the channels are not mixed up.

Also i think some games were crushing or unstable cause i think rgb and alpha channels values are not compatible (i guess rgb is for example from 0 to 200) while alpha is for example from 0 to 100, so if a higher value was applied to alpha channel cause of mixed up channels, game crushed.

could it be that texture is being applied with wrong coordinates (maybe a matter of "-" sing) the way only one pixel (the initial one) is common with visible area and the rest is outside visible area, hence not being visible, and that one pixel is being used to covering whole visible area instead?

French original

Bonjour j'ai Windows 98 se (Seconde Édition) et j'arrive pas à l'installer sur dosbox avec carte 3dfx vidéo comme ici, j'ai vu sur ce topic ici même windows 98 se (Seconde Édition) installer sur dosbox, mais je sais pas comment faire, il y a bien sur le forum un topic pour installer windows 95 mais que pour la 1er version de windows 95, il ne marche pas pour windows 98 se (Seconde Édition). J'ai 2 cd de windows 98 se (Seconde Édition) un bootable et un non bootable et 1 disquette bootable de windows 98 se. J'ai Windows Vista Home Premium 32 bits SP2 et Windows 7 Home Premium 64 bits pour faire marcher dosbox sur pc cpu Intel core 2 duo E6600 à 2,4 Ghz non o/c et 2 Go de RAM.
Ma question est comment installer Windows 98 se (Seconde Édition) sur dosbox avec carte 3dfx vidéo? je déjà sais faire des images de disque dur formater en fat16 avec Bochs et les monter avec imgmount sur dosbox, je peut en faire jusqu'à 2 Go par fichier image.

translated into English

Hello I have Windows 98 (Second Edition) and I'll not install it on dosbox with 3dfx video card as here I have seen on this topic here is Windows 98 (Second Edition) installed on dosbox, but I do not know how, there is indeed a topic on the forum to install windows 95 but the first version of windows 95 it does not work for Windows 98 SE (Second Edition). I have 2 cd windows 98 se (Second Edition) a bootable and a non-bootable floppy and a bootable windows 98 se. I have Windows Vista Home Premium 32-bit SP2 and Windows 7 Home Premium 64-bit to run on dosbox pc cpu Intel Core 2 Duo E6600 2.4 Ghz no o/c and 2 GB of RAM.
My question is how to install Windows 98 (Second Edition) on dosbox with 3dfx video card? I already know to make images of hard drive formatted in fat16 with Bochs, and go on with imgmount dosbox, I can make up to 2 GB per file photo.

MediaVistaIntel, this is off topic, this about emulating 3dfx with Dosbox. Your question is answered elsewhere in this forum.

The s,t coordinates seem correct. From the games I tested, it looks like they always use the floating point variant of registers, instead of fixed point, either way texture coords regs are converted into 64 bits fixed point, internally.

I'm replacing the rasterizer macros with a function, in order to make it debuggable. I also replaced the texture pipeline sub-macro, for tmu0 only.
I can't clearly see yet what's wrong; here's also the code, just in case you have better luck with it.

😀

i also noticed that vsync causes partial screen updates only together with z buffer turned on

yep, the precomputed reciprocals table was not initialized 😜 that's why perspective correction was not working.
there are still few minor graphical glitches, but it's mostly working fine 😁

Congratulations 😀

thank you 😀

I tested a dozen of games, everything seem to work mostly fine; here's what is left to do:
- there are few issues left with 2d elements drawing, in some games (see screamer rally menu and ingame hud)
- only one tmu is detected, instead of two, thus only 4mb of texture ram are used, the detection routine tests bit 6 of info->tmuconfig, which is calculated summing values taken from the framebuffer (?!?)
- the rasterizer is very slow; the next thing to do should be making it run on another thread;

here's the source code, enjoy!

- the rasterizer is very slow; the next thing to do should be making it run on another thread;

Just be sure this doesn't make things overly complex/unstable, quite long time
ago the output/rendering was in its own thread or so, which was switched on and
off a lot (finally off) because it never was on the spot.
But maybe the full rasterization can be separated enough to split it off into its
own thread.

About threads :

I avoided the crash of the multithreaded video capturing patch this way :

-thread_running was set to true/1 just before SDL_CreateThread (and not at the start of the threaded function)

-make thread_running an int so "thread_running=false;return rc;" became one line : "return thread_running=0;" (at the end of the threaded function)

I don't know if both are needed or just the first modification, but anyway, just my 2 cents.

PS : For a loooog time I thought I had a problem with MSVC compilation (MSVC has the reputation to be broken in some ways), but it was crashing when compiled for GNU/Linux with gcc too. 😉

wd wrote:

But maybe the full rasterization can be separated enough to split it off into its own thread.

that is a nice idea indeed.
the original implementation creates a queue where each workitem consists of up to 8 scanlines.
This way, threading is used at sub-polygon level; if an operation need the previous polygon to be completed, it just waits (poly_wait).

We may do something different, using sdl threads+events.
The whole chip handling runs in a single, persistent thread; dosbox sends reads/writes commands to the sdl event queue, which is processed by the "chip" thread in order.
This way we should also avoid reads/writes overlapping.

I'm not very expert of sdl events, but this little example seems to describe what we need.
please let me know what you think of it.

which is calculated summing values taken from the framebuffer (?!?)

They use the TrexInit1 reg to make the texturing chip output config data instead of pixel data. Apparently there is no other way to read from these chips.