06-9-2013, 07:07 PM | #1 |
FFR Veteran
|
Bad Programming Design you've seen in Commercial Software
I don't mean simply bugs (buffer overflows, failure to clean up/release resources, etc...). I mean the design itself is bad -- not just needs to be debugged.
I also don't mean things which are intentionally broken by design, such as DRM. Things I've seen in commercial games: Relying on undocumented processor behavior and/or processor bugs. Relying on exact processor speed, especially when requiring "not too fast and not too slow". Hard-coding and assuming that D: is your CD-ROM drive. Hard-coding and assuming that C: is the root of your Windows installation. Relying on undocumented Windows functions or behavior. Hybrid DOS/Windows game which required Windows for init, then rebooted into DOS to run. Where they were seen and why they were bad design even in their day: What they should have done: |
06-9-2013, 07:12 PM | #2 |
FFR Player
|
Re: Bad Programming Design you've seen in Commercial Software
Hard-coded input mappings.
SINGLE THREADED APPLICATIONS WHEN A MAJORITY OF PROCESSORS ARE MULTICORE/THREADED makes me so mad.
__________________
Last edited by FissionMailed1; 06-9-2013 at 07:15 PM.. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
|
|