-
Content count
148 -
Joined
-
Last visited
About viti95
-
Rank
Not enough potato
Recent Profile Visitors
630 profile views
-
Is there any port of Doom for Virtual Boy or Zeebo?
viti95 replied to Moonie's topic in Console Doom
Color depth shouldn't be a problem, Virtual Boy supports black + 3 shades of red (2-bit per pixel). Just create an optimized colormap + playpal and you're ready to go. This is a quick'n'dirty edit of how it should look (320x200, resolution on the virtual boy is a little bit bigger, 384x224). EDIT: The main issue may be differencing Hell Knights and Barons of Hell. Those should require a sprite modification. -
Is there any port of Doom for Virtual Boy or Zeebo?
viti95 replied to Moonie's topic in Console Doom
Virtual Boy has a 32-bit cpu running at 20MHz, that is more than enough. The main problem with the Virtual Boy is that it only has 64Kb of WRAM, which is 4 times less compared to the Raspberry Pi Pico, it would require a cartridge with aditional RAM. Also Doom is perfectly playable even with monochrome tones, so it could be done and be visually pleasant. -
I never do preorders... except for this one ^^
-
FastDoom: DOS Vanilla Doom optimized for 386/486 processors
viti95 replied to Redneckerz's topic in Source Ports
@Blzut3 is right, that technique is only usable on EGA/VGA cards, the MDA and CGA cards cannot redefine the characters. That's why I had to create a new specific text mode for the IBM MDA, as it doesn't support any kind of graphics mode. Redefining characters is pretty powerful, this demo is a pretty good example I've been testing with it's creator. This demo works at 60fps on 8086 computers (custom text mode, 40x30 characters): -
FastDoom: DOS Vanilla Doom optimized for 386/486 processors
viti95 replied to Redneckerz's topic in Source Ports
Yeah this definitely requires custom assets to get better results. BTW new release: FastDoom 0.8.12: - New video mode: IBA MDA text mode (FDOOMMDA.EXE). Just for fun, quick'n'dirty - Small optimization on gameplay code and melting screen functions - Fixed corruption on VGA palettes (issue #75). Force fix if still doesn't work using the command line parameter "-fixDAC" https://github.com/viti95/FastDoom/releases/tag/0.8.12 -
FastDoom: DOS Vanilla Doom optimized for 386/486 processors
viti95 replied to Redneckerz's topic in Source Ports
For now it's just quick'n'dirty support for the IBM MDA, guess I'll make it better someday. -
FastDoom: DOS Vanilla Doom optimized for 386/486 processors
viti95 replied to Redneckerz's topic in Source Ports
¯\_(ツ)_/¯ -
FastDoom: DOS Vanilla Doom optimized for 386/486 processors
viti95 replied to Redneckerz's topic in Source Ports
The problem with interlaced rendering is that it requires very fast screen updates to look reasonably good, and here we are dealing with low framerates most of the times. I'm pretty sure that can cause some headaches. The other idea is good, but the Doom engine requires big changes to allow different rendering resolutions at the same time (I did some testing and failed miserably, for example rendering the sprites at high quality while rendering the scene at a lower one). Old 386/486 computers benefit a lot from sending less data via the ISA bus, and that is one way to do that. Regarding CPU optimizations, the first executables were optimized for 386 and 486 cpu's, and in all the testing done the 386 executable was always the faster one (also smaller). That's why I decided to release only the executables optimized for the 386. I guess OpenWatcom isn't very good at optimizing code, compared to newer compilers. Again, this requires time to research, and I'm pretty limited right now. -
FastDoom: DOS Vanilla Doom optimized for 386/486 processors
viti95 replied to Redneckerz's topic in Source Ports
I've tried to use the OpenWatcom debugger but it always have caused lot's of troubles and it's very unstable. Don't know exactly why. Even on a local machine (DosBox-X + com2com + OpenWatcom for W64) which shouldn't have communication problems, didn't work reliably. For now I debug using the DosBox-X debugger and the "i_debug.h" functions (requires a second monitor connected to a MDA/Hercules card, or DosBox-X running with the secondary monitor enabled). -
FastDoom: DOS Vanilla Doom optimized for 386/486 processors
viti95 replied to Redneckerz's topic in Source Ports
New release! FastDoom 0.8.11: Changelog: - Optimized backbuffered video modes: Hercules, CGA B&W, Plantronics ColorPlus, EGA, ATI 640x200 - Small optimization on multiple modulo operations, sound code and gameplay code - Fixed music initialization volume (@deat322) - Fixed mouse move fordward button (@deat322) - Include full FastDoom version number (issue #72, @SpitFire-666) Download: https://github.com/viti95/FastDoom/releases/tag/0.8.11 -
-
Jackass Forever. 11/10.
-
FastDoom: DOS Vanilla Doom optimized for 386/486 processors
viti95 replied to Redneckerz's topic in Source Ports
New release! FastDoom 0.8.10 Changelog: Added new video modes FDOOME16.EXE => FastDoom EGA 160x100 FDOOME36.EXE => FastDoom EGA 80x100 (122 pseudocolors) FDOOMT43.EXE => FastDoom 80x43 16 colors text mode (only EGA cards) FDOOMT86.EXE => FastDoom 80x43 16 colors text mode (virtual resolution of 80x86, only EGA cards) Multiple optimizations for special backbuffered modes Better colormaps / palettes for black&white modes, and 16 color dithered modes Removed FDOOMV.EXE, the scaling was horrible and didn't look good at all Revert custom palette for VGA 160x100 mode. The attribute controller requires the display to go blank to change each color association. Not doing this causes some random screen glitches while changing the palette (which I haven't been able to solve, since the hardware works this way). VGA 256 color mode doesn't have this problem Download: https://github.com/viti95/FastDoom/releases/tag/0.8.10 -
This is great! Good work! I'll try it on my 386 and see how playable it is :D