Sorry for such a late reply, middle of exam season and I've had piles of work to get through... The design decision for the updated flight computer due to reduced cost, redundancy and modularity was to distribute the systems accross many ATMega 328s networked over I2C. However, I did get a pure C team to look at the support programs for flight data analysis and telemetry and such which I'd written in pascal to go 'wow' and convert them. One is currently over the moon about how easy and portable lazarus is, how readable the code is, how easy the migration was but most importantly - how powerful the fcl is Also got a few statements about how 'suprisingly' feature rich pascal is and how it takes out a lot of the unnecessary complexity of C based languages. Even have a handful of VB.Net users moving over.... Call it a victory perhaps?
Up the ante, buy an ARM Cortex-M3 processor(STM32F103 is quite nice), and write in Pascal Doing that you get a 32bit ~72 MHz processor. You could even go up to Cortex-M4F which usually run around 100-190 MHz
So far, I don't like it at all! Maybe that will change in the future cheers, Paul
Sounds neat, hope to see more soon.
wglShareLists
You have to be very careful with multithreading and API/library calls. Many libraries are not "thread-safe", and can do anything from work perfectly 9,999 times out of 10,000, to turn your cat plaid. You also have to make sure that YOUR code is "thread-safe" as well, and also learn when and how to use various synchronized-access resources (mutexes, semaphores, spinlocks, critical sections, etc) to serialize access to shared code and data structures. It is exhilarating when it works, and maddening when it doesn't. My main forte' is multithreaded networking and file I/O. I am studying graphics libraries and APIs to see where multithreading can possibly be used, but so far, it's been a mixed bag because most graphics work is REALLY not "thread-safe". Generally, games (and graphics applications in general) keep the rendering to a single thread, with the exception of some of the "big guys".
Ya, the work is before all the rest
working... LD is priority ATM though. then is gcse exam week, so R&D is on hold for now
cool idea, keep it up
It all sounds good man cheers, Paul
Sometimes online backup is much better solution when a backup folder on HDD,Memory Card or USB Stick.
Not yet, fully anyway... I'm having a nice time trying to tell fpc how to build an elf for 2 cores and then put that into and nds which is a pain. Other than that, sdl is for resource loading from just about any file format, dump that and its gl only for video. edit: read the wiki thorugh again and realized: oh, you dont need the 2 cores used? Which means I may have a breakthrough as early as this afternoon
So you said that you got it working on the Nintendo DS Lite? I guess this is the SDL version then? OpenGL wouldn't work there... I think there are some licensing issues with DS and SDL too due to static linking or something from memory. Legolas would know more than me probably cheers, Paul
In theory I see no reason why not. The use of sdl is highly specific and a trimmed down version really only uses opengl (for video anyway which is the main purpose)... I did come up with an interesting test just to check though which I will be carrying out later this week and bloggin about: firing up Prometheus on my nDS's ARM chips I think its a verison of OpenGl it uses so hopefully... Andru, I have found a nice perk: meego is an i586 distro... So if you have an x86 or x86_64 cpu u can boot up meego and run all the stuff from there... Oh, and qemu-gl crashed? not again... XD I guess if prometheus starts working on everyhthing I might have a winner. Although looking at ZenGl, you sure as heck don't have far to go to get that universal either. If it wasn't exam time I would say Race-Ya but then again =] gintasdx, I hope it does work on android... I sure hope it does... Might get an opportunity to try this out in the next few weeks so we shall see. Hopefully that will be a nice blog post: prometheus on ARM: NDS & Android Edit: wait wait wait, hang one. Did I read that right: there is something Arch does not have? O-M-G I never thought that would ever happen. Like ever.
Emm,if this is works with ARM processor tablet maybe this engine could work on Android too?
Without real device developing for MeeGo is such an a**pain... really, because I can't use MADE(MeeGo SDK tool) under my ArchLinux x86_64(becauyse there is no packages for my distro, and no tarballs, only deb's and rpm's in repositories...), also qemu-gl crashed on my 64-bit system, so I can't start any of MeeGo images... Also I tried Xephyr(as I do with Maemo), and no luck at all. But inside emulated Ubuntu 10.10 MeeGo inside Xephyr works, but without OpenGL ES support... Sometimes I hate big corporation, because they don't know anything about really cool distros >_< update: So I copied over the source to a USB, booted up meego and half-heartedly inserted the USB disk. just read this again and understood that this is an good idea...
Cool! Keep em coming dude One thing, the only issue I have with your coding style is that you seem to be using TAB characters and not spaces in the code... This means that when I view the code in a text editor, I get 12 space indenting for each TAB! cheers, Paul
Aye, infinite glory to those that succeed. But really, it's not that hard. Just, keep it simple, real simple. Like if you had to explain it to a five year old.
I totally agree - TK 422 is there are a problem? Sorry, just another BSOD. Hey, wait a minute - your on linux! After him!
It was then that the evil sith brought Code Glitch an official "storm trooper" uniform in the form of a white jacket.
Blog Categories
Recent Visitors
Go to Profile
Mark as Read
