Ipl 2013 Games For 320X240
Outi Foote
This actually had much better performance in 640x480 software and is SOMEWHAT playable, though I had to guess the framerates are in single digits. The Half Life Uplink demo I had was more like seconds per frame.
Even better though, on the Video Modes tab it has the option to run in a window. If I do this it lets me select resolutions down to 400x300.
400x300 is actually pretty playable on the P5-200 MMx (I'm guessing low double digit framerates), albeit it's a small window to play in. Still, progress.
This PC also seems to be paging about 30 MB of virtual memory, so I'm guessing that's hurting the software render performance a lot. I'd be interested to see how upgrading to 96 or 128 MB helps if at all for software render.
last time i looked into this i was under the impression that 320x240 was removed in 1.1.0.1, but can't find a source for that info now unfortunately. but look for the oldest possible CD retail version. as for newer patches, half-life's version history was really all over the place even pre-steam, see the infamous crowbar bug...
i'm very certain i had uplink running in 320x240 at one point though, either there are multiple versions of that demo around or it's a driver issue on your side. i'm pretty sure i used a matrox millennium when i did that.
also, if you're running an intel chipset, it will only cache 64 MB of RAM so adding more would cause a performance penalty. the game will run very slow either way on such a machine though: =P-DfQ05OACU
Thanks. I did try 1.1.0.1, the settings available were the same but performance was somewhat worse. I noticed 90 mb virtual memory paging. I rolled back to 1.0.6 GOTY and it was back down to 30 mb paging. So far that seems to be the best performer for me.
low-res software rendering support was very commonplace in shooters of the day, even in win95, you may check if something like unreal/hexen2/outlaws shows those modes. half-life was really a unique case in terms of patching those modes out, which made that p133 minimum requirement on the box even more bizarre than it already was.
For HL retail 1.0.0.9 and 1.1.1.0 at least, resolution list for windowed mode (Software, OpenGL or Direct3D) is hardcoded. The same list is also hardcoded for fullscreen OpenGL, but for Software and D3D fullscreen, resolution list is enumerated from the system, but the resolution must pass few checks for it to show up on the list:
From a very quick test, HL 1.1.1.0 doesn't seem to have an issue running at 320x240 in software mode after removing that check for width below 400, though when the game outputs white text on the lower portion of the screen, in Hazard Course for instance, multiple lines tend to overlap. Perhaps the resolution enumeration also takes color depth into account as old HL runs at 16-bit color depth by default.
Given the state of the software renderer in those old WON versions, I think only aspect ratio check and height not above 1024 makes sense for software rendering specifically, hardware accelerated rendering should be fine for the most part in greater resolutions.
hl.exe needs to be patched with OllyDbg or similar debugger. Both versions 1.1.1.0 and 1.0.1.6 at least have unique CMP EBP,190 command inside that may be found when using search (CTRL + F), the code must be modified in the way that this comparison instruction along with a jump instruction afterwards are removed, easiest is just using the context menu option to fill that space with NOPs, then use the right-context menu option to save changes back to disk.
When I was still working on these things few years back, I went out of the way to remove the gaps in such places to make the code cleaner, though obviously that sometimes, depending on number of changes in a particular part of code, it may give appearance if someone is comparing original and modded executable with a hex editor that there's more changes than there really are. I have hl.exe version 1.1.1.0 (the one from my patch here) currently at my fingertips, so here's the version with that check removed.
So since it's based on that patch, stock 1.1.1.0 is a prerequisite, there's no hardcoded resolution list anymore, resolutions are taken from the system and it has a couple of other fixes mentioned on the patch's ModDB page, at least those that are in hl.exe. If I remember correctly, hw.dll only has D3D mode related fixes while the separate .asi files are for MP3 and FOV fixes.
Is this not the cutest little display for the Raspberry Pi? It features a 2.8" display with 320x240 16-bit color pixels and a capacitive touch overlay. That's right, instead of a resistive touchscreen, which requires a fingernail or stylus, you can now use a fingerpad. The screen looks much nicer, with a black bezel and glass overlay. If you don't need a capacitive touchscreen, check out the resistive touch version.
Use it for console access or easily pop up X11 onto the PiTFT for a mini monitor, although its rather small at 320x240. Instead, we recommend using PyGame or other SDL-drawing programs to write onto the frame buffer.
Adafruit NeoPixel Digital RGB LED strips come to us in 4 or 5 meter reels with a 2 or 3-pin JST SM connector on each end and separated power/ground wires as shown in the picture below. If you order a full 4 or 5 meters, you get the full reel with both connectors installed.
If you buy less than a full reel, you'll get a single strip, but it will be a cut piece from a reel which may or may not have a connector on it. If the piece comes from the end of the reel, the connector may be on the output end of the strip!
So I'm lazy, or I'm hoping to benefit from kernel changes and maintenance. It's confusing as to what the correct way to define an LCD in the device tree for Linux. I've read the binding documentation and managed to run `fbset' to change the resolution to 320x240 along with guessing the timings. However, this is NOT clean and gives bad LCD flicker on startup. Also, I am still not getting the right timing settings.
Turns out I didn't need half that much. But it would have been easier to enter the LCD properties in a device tree rather than editing the driver. The following is what I did for a Hantronic HDA350-2S LCD panel,
Did you find a resolution? I'm fighting with the same problem, I have a generic 800x480 Chinese display but modifying my device tree doesn't modify my blank LCD screen. Changing fbset doesn't change anything but its values. Is there a generic driver with its corresponding device tree node?
lcdif doesn't seem to be working for iMX6-Solo even though it describes the connected LCD. There are registers that can be configured for LCD as well but they are not well documented. Anyone have any suggestions on what to do next?
7fc3f7cf58