Aley Keprt wrote: > Okay. > I see we are on the same ship. *gasps* I think I need a lie down...
> Oh, get back to the ground. > I've never heard about CPU as an object. Current multi-CPU emulators tend to have a structure full of the CPU state, which is effectively treating it as an object. The big difference is that they're accessing a fixed global location for the structure, and the state to use is copied in and out of that location around where the CPU emulation is run. It means there's no 'this' baggage to pass around and things stay lean. <snip> > How we can discuss this, when you is the only man who have seen > the source code? er, but know of at least 7 people with the source code! I've sent it on request to everyone who's asked for it, except recently when Adrian asked and it was not in the best of shape (as Dave Laundon can confirm!). Actually, you've never contacted me to ask for the source anyway! I'm always happy to send out the source matching the latest available binary, to comply with GPL, but that's getting very out of date now. Availability of more recent sources is only at convenient intevals after batches of changes, so as not to have people fixing/enhancing stuff that's still in progress. I'm still changing the code on a daily basis, so things remain quite volatile. An updated binary is well overdue, so I'd like to get one out before too long. > I think all computers use some virtual (or 'scan') key codes, so the > keyboard system can be built up from some callbacks, > and 'update' function called each frame. In 'update', the driver can call > callbacks for each key pressed/released during the last frame, giving the > key code and its state. That's what Input::Update() already does :-) New ports just need to implement Input::Init(), Exit() and Update() for their platform-specific handling. > I call this 'big pink pig'. :-))) > What a poet am I. > It was a hard work, wasn't it? Yes, tho I think it was worth the effort to experiment with what could be done. Current video features are simpler than previous versions, tho having full-screen and windowed with optional overlays and support for devices not allowing video memory access, means it's still not simple by any means! > If I programmed it, I select one particular fullscreen mode (or > two), and do nothing more..... 320x240 mode is no longer used, leaving 640x480 for pretty much everything (except the 5:4 full-screen mode, which needs 800x600 is needed to see the full visible area). > Of course. > But I preffer classes with static methods over namespaces (dots, > instead of 4-dots :))) hmmm, but C++ uses the same notation for namespace and static methods - namespaces seem to fit things better at the moment too. Si
