View Single Post
Old 12 September 2015, 20:36   #108
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Originally Posted by phx View Post
Hollywood is great, but when the games don't run on an 1 MB A500 it makes no sense, IMHO.
A 1MB A500 is the best target currently for a wide audience but it is challenging for a good game when not using assembler and banging the hardware which have steep learning curves and other disadvantages. Most active users have several MB of memory especially with UAE and FPGA hardware gaining in popularity. Even targeting a 68020 with 2MB of memory gets most active Amiga users. Unfortunately, targeting AGA loses many ECS owners unless RTG is also supported which isn't too difficult although sometimes slower and banging the hardware is out (IMO, the OS should be used when it is fast enough and capable enough).

Low spec games are great but I believe higher spec targets can be more easily created. I think this was some of Olaf's point. However, the Amiga slow motion revival is not to the spec Hollywood would need. Maybe some kinds of non-processor intensive games would be possible on targets other than UAE. Hollywood itself is compiled so improving compilers could help the situation but new more powerful 68k hardware than even the FPGA Arcade and Mist would be necessary and available at a reasonable price. The Natami link makes me sad as it was the right target and had so much promise.

Originally Posted by ReadOnlyCat View Post
This is off topic territory but as an example many early compilers generated
opcodes for each function call which is both useless and inefficient. The last versions of Lattice did not do it however if I recall correctly. I remember being anxious that it might generate these at the time after I bought it.
GCC has problems in most versions with generating LINK/UNLK even with stack frames off. Vbcc and SAS/C do not have this problem. The default in vbcc is to have stack frames off because it generates the most efficient code .

Originally Posted by ReadOnlyCat View Post
Gcc did not have this problem however and when I worked a bit with a play version of quake ported by Samuel Devulder on my 1200 in the 90's I recall that the generated assembly code was not too bad. It could be improved obviously but it was far from horrible. Samuel's "popt" peephole optimizer (on Aminet) managed to squeeze a few more cycles out of it but not an enormous amount.
GCC 2.95.3 had a solid 68k backend but lacked a good peephole optimizing assembler for the 68k. Vbcc today has the world's best 68k peephole optimizing assembler but the backend is basic. A peephole optimizer (and instruction scheduler) is somewhat limited on the 68k because most instructions set the CC. Vbcc does many sophisticated high level optimizations too. There just isn't much motivation (beyond fixing bugs) to improve the 68k backend with the current state of the 68k and Amiga. Lack of motivation for a dying platform is the reason why many games are never started or abandoned. Is there any other way to solve this problem besides new 68k Amiga hardware?
matthey is offline  
Page generated in 0.03951 seconds with 10 queries