Native dev on oldschool machines. Who does that?
category: general [glöplog]
I'd like to know which groups use their native oldschool machine to make demos. I'm going to make a demo about it.
I see cross-dev as dopage. No denying it give **spectacular** results with less effort. Yet it goes against the beauté du sport. While it still shows what the computer is able to do, it fails to demonstrate what you can do with the computer. I also find it a bit sad that home-brew artistic creation shall follow business practices.
It's only my noble opinion. Although highly grounded, it isn't meant to convince anyone. It only matters because most demomakers care about the audience (the vanity component), so as part of the audience I'm sharing what makes me tick and awe.
tl;dr: Cross-dev sucks, computers mostly suck, don't use steroids, listen to Devin Townsend, don't change my mind and let me know if you create on your old-school box.
I see cross-dev as dopage. No denying it give **spectacular** results with less effort. Yet it goes against the beauté du sport. While it still shows what the computer is able to do, it fails to demonstrate what you can do with the computer. I also find it a bit sad that home-brew artistic creation shall follow business practices.
It's only my noble opinion. Although highly grounded, it isn't meant to convince anyone. It only matters because most demomakers care about the audience (the vanity component), so as part of the audience I'm sharing what makes me tick and awe.
tl;dr: Cross-dev sucks, computers mostly suck, don't use steroids, listen to Devin Townsend, don't change my mind and let me know if you create on your old-school box.
Quote:
I see cross-dev as dopage. No denying it give **spectacular** results with less effort.
Of course, because cross development magically unlocks all kinds of hidden features in retro hardware not accessible otherwise...
Just because it's harder doesn't mean it's better.
Maybe actually make a demo about it before posting. But nobody will be able to tell the difference, or really care.
Maybe actually make a demo about it before posting. But nobody will be able to tell the difference, or really care.
No, like dopage alone won't make you magically win the Tour de France. You make your choices based on your own set of values, in my book that doesn't prevent this analogy to remain pretty solid.
@lynn. I do care, and I am just asking if anybody else does.
Quote:
No, like dopage alone won't make you magically win the Tour de France.
With that analogy, crossdev is like training in a simulator - it's more convenient than flying across the world just to train, but in the end you still have to perform in the original environment.
@Gargaj. Your analogy is spot on for the prod, not for the development itself. Each time you precompute something using all the power of a modern PC, you are not in the original environment.
There is a reason why Wild & Real-Time are separate categories.
There is a reason why Wild & Real-Time are separate categories.
Quote:
Each time you precompute something using all the power of a modern PC, you are not in the original environment.
You do know that cross development is not the same thing as precomputing something?
Quote:
@Gargaj. Your analogy is spot on for the prod, not for the development itself. Each time you precompute something using all the power of a modern PC, you are not in the original environment.
That's why my analogy is spot on. If you made simulations that tell you which line you take in the Tour De France, you still have to ride it.
less Tour De France, more Devin Townsend!
I'm no expert, but are you actually going to type for hours straight for days on end on those keyboards? I'm not sure if that is healthy. I mean the C64 came with a mouse if I'm not mistaken but times kind of moved on.
Quote:
Yeah, for example DEVIN TOWNSEND PROJECT - Deadhead (Live at Royal Albert Hall)listen to Devin Townsend, don't change my mind and let me know if you create on your old-school box.
is this the retro-approach to the "stop using tools" discussion?
I'm afraid so, and it's even dumber.
Also nothing is stopping you from precomputing sine tables etc. on the original hardware, it just takes a bit longer. Bytes are just bytes, them being influenced by what hardware they were computed on is pure nonsense.
And this discussion doesn't even make sense for platforms w/o a programming environment.
Also nothing is stopping you from precomputing sine tables etc. on the original hardware, it just takes a bit longer. Bytes are just bytes, them being influenced by what hardware they were computed on is pure nonsense.
And this discussion doesn't even make sense for platforms w/o a programming environment.
But of course it does make sense, if you want to go that route. You could restrict yourself to the original cross development environment. That would e.g. be an Atari ST for Atari 7800 development (linky).
You're mixing up a few things. I'm doing cross-dev in that I edit and assemble on a Linux PC, but I'm running against a native oldschool machine using a network adapter. I do care for the audience in that I want to give it nice visuals and an insight to my vision of demo making. Precalculated animations and coding against emulators suck.
I can only speak for weird platforms but this thing is not possible to develop for on the real HW :)
(re: what poro said)
That aside, if we stretch the term "dev on machine" a little and let coding on PC and only testing on the hardware count for this purpose, then.. well, my only advice is DON'T.
1) hack, 2) reflash (30 sec - 2 min EVERY time), 3) crash and burn, 4) repeat
That was pretty much my dev cycle in the beginning. Things became more interesting and MUCH quicker to iterate after extending the demo framework to compile on both PC and AVR, emulating hardware-specific stuff like the LCD and geneal slowness of the CPU.
Also, consider everyone needs comparable dev hardware, which is a problem that scales exponentially(?) with the wildness of your hardware. This thing only worked out in the end because uctumi could work with an exe file that could load & convert the music.xm and then play it in the same way the hardware would, including sync markers and everything.
But you probably mean "standard" platforms like amiga or c64.
TL;DR Go for it, but don't complain if native dev gets you stuck in development hell =)
Being able to iterate fast is super important, as long as you can establish that somehow it's probably going to be fine.
(re: what poro said)
That aside, if we stretch the term "dev on machine" a little and let coding on PC and only testing on the hardware count for this purpose, then.. well, my only advice is DON'T.
1) hack, 2) reflash (30 sec - 2 min EVERY time), 3) crash and burn, 4) repeat
That was pretty much my dev cycle in the beginning. Things became more interesting and MUCH quicker to iterate after extending the demo framework to compile on both PC and AVR, emulating hardware-specific stuff like the LCD and geneal slowness of the CPU.
Also, consider everyone needs comparable dev hardware, which is a problem that scales exponentially(?) with the wildness of your hardware. This thing only worked out in the end because uctumi could work with an exe file that could load & convert the music.xm and then play it in the same way the hardware would, including sync markers and everything.
But you probably mean "standard" platforms like amiga or c64.
TL;DR Go for it, but don't complain if native dev gets you stuck in development hell =)
Being able to iterate fast is super important, as long as you can establish that somehow it's probably going to be fine.
Was there no cross platform dev from mainframes to micros back in the day?
Developers have ALWAYS been writing code on various machines that weren't the native target platform. Like using a BBC Micro with a cable to program the 48k speccy because you got a disk drive and a better keyboard etc. An Amiga 2000 with 030 to write games for A500...
Yes go make a demo about it.
Yes go make a demo about it.
I code all our smfx demos on the real hardware. This way the process of developing a demo is as streamlined as possible. Quick workflow cycles to development and testing and not to mention including assets provided by team members works nicely! I dont understand why anyone would ever use any crossdev tools, or develop demos on other hardware for that matter. There is simply no reason to.
If you're not developing like this, you're not worthy.
( jk, you all are lovely beautiful human beings ;-* )
( jk, you all are lovely beautiful human beings ;-* )
I code my demos using old native tools, but inside an emulator. Sure hope everyone is ok with that!
@m_dr_m: As a coder whos code was wrecked by TurboAssembler on C64 in his youth dozens of times and even more often, pretty pretty please, with cream on top, STFU ;-)
People spend more time on here arguing about the right way to make demos than actually fucking making them.
What dodke wrote: One of the most famous Oric games, Xenon 1 (IJK Software) was not developed on the Oric, it was developed on a BBC computer with floppy disk drive system and then transferred to the Oric using some cables, because the machine was faster and had a better resolution, and it made it possible to use the memory more efficiently because you did not have to waste some ram for the assembler.
Cross development is not something new, it has been used for a very long time, heck, all the games for PlayStation, Xbox, Dreamcast, GameCube, etc... are cross compiled.
Not using features provided by modern work environment is just choosing to be less efficient for the sake of a purity concept that has never existed.
Cross development is not something new, it has been used for a very long time, heck, all the games for PlayStation, Xbox, Dreamcast, GameCube, etc... are cross compiled.
Not using features provided by modern work environment is just choosing to be less efficient for the sake of a purity concept that has never existed.