tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] TCC as portable module compiler


From: Alexander Gladysh
Subject: Re: [Tinycc-devel] TCC as portable module compiler
Date: Tue, 18 Mar 2008 17:49:51 +0300

On Tue, Mar 18, 2008 at 4:49 PM, Kenneth Forsbäck
<address@hidden> wrote:
> Yes, I've used Lua and it is quite nice indeed ^_^ However, at the
>  moment I am not too willing to switch over to a fully scripted game. Lua
>  might indeed be very useful for other parts of my game, however, for the
>  modules/plugins, it might not be such a good idea. One thing where I
>  would absolutely not use Lua is the hardware simulator. I could use LNUM
>  to use integers instead of doubles, but I still would not want to switch.

I've missed that "hardware simulator" in you previous posts.

>  I am not a fan of pixel-junkie games, and have never intended for my
>  game to be anything for Super-Duper-Tripple-Nvidia-SLE-Nuclear-Driven
>  Graphics Cards or whatever the hell they call it. Too much scripted code
>  and it is going to rob other parts of the game of valuable cpu time.
>  Yes, computers are very fast thesedays and have plenty of memory, but
>  the old C64 philosophy is still as valid, every cycle and every bit is
>  worth its transistors in gold ^.^

>  Lua is roughly 10 times slower than C, so it is actually quite fast,
>  faster than most competing dynamic languages, but that would still mean
>  10 times less code in the hardware simulator

In my experience, it is worth to prototype in Lua and rewrite critical
parts in low-level language afterwards as needed. It brings greater
flexibility to architecture and less premature optimization. That is
true to some extent only of course, because if you're not careful, it
is relatively easy to screw your code to the point where such
refactoring would cost too much. However I believe that it is usually
better to get working but slow code ASAP than get stuck in fighting
with ugly monolith of pain which maybe work fast, but is exhausted its
flexibility before that mission critical 10% of functionality happen
to be implemented.

This is getting too generic though -- not knowing specifics of your project.

Alexander.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]