Jump to content

potatohead

Members
  • Content Count

    4,794
  • Joined

  • Last visited

  • Days Won

    16

Posts posted by potatohead


  1. Well, I would wait for him to complete his project. Then, it's a working 3D engine that can do some stuff.

     

    At that point, hacking on it to generalize input to it would make some sense for other projects. My .02

     

    Doing it now sort of adds complexity to what is already going to have some. And there are memory constraints. Probably important to do the project and not do other things, until that's done so that the RAM is there for the project. Again, my .02


  2. Well, VRML is a very significant expansion over the simple macros he's got here. Just parsing the average file, handling the transforms and displaying ANYTHING would very likely exceed the RAM on most Ataris, and the compute requirements would be insane. Like, try it, "wait a day" and see if stuff shows up. Maybe not that bad, but not interactive either, IMHO.


  3. Nice shortcut on the 90 degree view angle. Seems to work out well too.

     

    Here's a rundown on the various things just discussed.

     

    http://www.codinglabs.net/article_world_view_projection_matrix.aspx

     

    I've got a familiarity with this from an entirely different perspective. (robotics, CAD, etc...) It's the same sorts of math.

     

    Honestly, I'm kind of impressed so few bits actually worked out well. Nicely done so far!

     

    A while back, I toyed with doing something like this on the little micro I program on from time to time. Might be some nice shortcuts and optimizations here over time.

    • Like 1

  4. It is just HGR, but yes. The renderer takes full advantage of how the Apple works.

     

    One alternative, if a 5th color is worth it, would be to make a bitmap char mode. Stack them up and use DLI to set new charbase values so that the screen is all unique chars.

     

    This is as convoluted as the Apple is, but it would be 5 color and a renderer will be similar.

    • Like 2

  5. Re: Converting apple graphics.

     

    For one, they don't convert well, due to the pixel art often taking advantage of single pixels having color. Think about graphics 8 vs graphics 15. In graphics 8, we get 320 pixels, and a single one of those can be turned on, and it will appear as red or blue, assuming a black background and white foreground. In the 4 color modes, a single, small pixel, can't ever be turned on. There are only 160 pixels, but they have four palette colors.

     

    So the Apple art loses some detail because of this.

     

    However, if one did want to convert, the 7 pixels per byte means having to work with a whole scan line, or two bytes minimum to convert. There are even and odd bytes. This means even bits in an even byte will show as one color, say orange, and those same bits in an odd byte will appear as another color, say green. This is because the number of pixels per byte isn't even. It also means Apple games require two sets of images, or they need to perform some shift kind of operation while drawing.

     

    Working with two bytes, back to back, helps, because that bit pattern will work across the screen and a color translation to 4 color modes will make a lot more sense.

     

    The X is the high bit, used to color select.

     

    x1001000_x1001000

    -eoeoeoe_-oeoeoeo = 14 screen pixels

     

    The "-" is not displayed, "e" and "o" represent even and odd pixels as seen on the screen, which represent two colors. The "_" is just there to separate the two sequential bytes. Notice how the same bit pattern presents as different colors?

     

    Most other computers, and for sure the Atari, have 8 bits per byte that actually are pixels. The trade-off is only getting two artifact colors, but the gain is the same bit pattern displays the same colors no matter where it's at on the display.

     

    01001000_01001000

    eoeoeoeo_eoeoeoeo = 16 screen pixels.

     

    That's the difference, and why conversions don't map directly to other machines.

     

    The actual pixels themselves are basically the same size. There are just less of them on an Apple display, due to that high bit being used as a color shift, not a pixel. 40 bytes per scan line for both machines.

     

    Of course, this all makes draw routines on Apple computers complicated. A look up table for "Y" addresses makes sense, and is fast, and common to a lot of machines. C64, Atari, etc... The Atari has linear bytes, which make for a fast, simple draw routine. The Apple is messy because of how the even and odd pixels work out. Two bytes of shift data are needed. The C64 has it's high resolution pixels ordered for fast character drawing. Linear bytes stack vertically on that one. So it needs lookups in both directions, or clever draw ordering...

     

    @Franco: Nice work so far man!

     

    IMHO, using the Apple art as a reference is best, because of the single, high res, color pixel being possible on a high resolution screen, but not on a 4 color screen.


  6. E-mail him about it. I just did.

     

    Who knows?

     

    A quick glance through the comments and searching related to that partial code review shows how this game influenced a lot of people. I've kept an Apple around just because of it. Other things too, but it's just beautiful.

    • Like 2

  7. Merlin was also used to assemble Atari games, written on an Apple computer.

     

    Personally, I would setup on Merlin and perform a build on Apple. Make sure it works.

     

    Now you've got a base.

     

    Setup some test programs on Atari, make some graphics / sound decisions, and then take a chunk of the PoP code and assemble it for Atari.

     

    When I was more motivated to work on this, and I actually did have some time, I got stuck on assembler issues. I really wanted a fresh build of PoP on Apple.

     

    Now that's possible.

     

    http://forum.6502.org/viewtopic.php?f=2&t=2223&start=30#p25628

     

    https://github.com/adamgreen/snapNcrackle

     

    https://github.com/adamgreen/Prince-of-Persia-Apple-II/blob/build/Notes/pop-build.creole

     

    That build was done by writing an assembler to do the key things Merlin would do. Not sure using it for Atari would make sense, but Merlin 32 will understand nearly all of this code now.

     

    And that one can build games for Atari. Bill Budge did this, among others. Write Apple version, then modify for Atari. (which is why some Apple games never really used Atari specific resources....)

     

    BTW, that code does include the level editor. You could build that, get it modified for 8 pixels / byte instead of 7, generate new level tiles, and then carry on from there. Doing that will require a basic graphics screen setup for ANTIC, and rewriting the draw routines. Apple draw routines are complicated because the damn screen is complicated. You get some code space for free doing this.

     

    The other big part of the editor is the disk I/O routines. A simple layer to translate tracks and sectors to blocks would be needed at a minimum. That way all the many disk calls still make sense.

     

    You can find Merlin here: http://brutaldeluxe.fr/products/crossdevtools/merlin/

     

    PoP is a high res game. The only double high res is in the title screens. Might only be one screen actually. Apple's do generate 4 artifact colors, where Ataris only generate two. But those artifact colors are always on byte boundaries.

     

    This makes PoP a 6 color game. PITA

     

    Lots of ideas in this thread to address that. :)

     

    Finally, here is a code review. This is NICE! It didn't exist before. Reading it now.


  8. I guess I see it differently. There is some small chance he might make a few bucks on it, so he's got it. He might just be speculating too, buying up active, but expired domains, hoping people will pay. He could let it go too, if that's what he's doing. But, he might go a cycle or two before doing that. Keeping it is really, really, really cheap. Almost not a worry.

     

    On the other hand, you've got stuff you want to do and some things you made out there. Linking everything over to the others will fire that all back up, and it won't take long before the .com is no longer even a consideration. He could drop porn on it, or some ads. Who cares?

     

    The best option is to make a move that renders whatever move he makes irrelevant. That's why picking up the .net and .org and moving on is the best move. He's out. No worries. Doesn't really matter what he does.

     

    After some period of time, he may well just give up and move on, or he's got some real use, whatever. You won't care anymore because you've just setup on something you have and can setup for auto renew and all that stuff.

     

    TL;DR "Screw this guy and make sure he gets nothing"


  9. opry99er.net and .org are available right now.

     

    Why not pick up one of those? People can update their links, you put the word out, and it won't take much for the whole works to center in on the new one.

     

    I use gandi.net, and both were under $20, and that can be had much cheaper. Get 'em both, set them to auto-renew and maybe that guy who has the .com will realize he's got nothing and let it go, at which point you pick it up.


  10. I've an old T60 laptop I keep around because it's all setup with years of cool development stuff. Soon, I won't need it anymore as I'll have setup all I want on newer machines.

     

    It's fan is crap. Replaced it. That one is crap. I don't want to do it again, so...

     

    I don't need the machine at full speed. Running XP, it does fine clocked down to a modest and cool rate. But the BIOS wants to see that fan work at boot, and sometimes the fan starts rough, chatters, and the machine will fail.

     

    Enter the air can. Yes, I keep one next to the machine, power up, count one, two, spray pfffft into the fan, where it spins up, zzzzip, and the machine boots just fine. After that, who cares if the fan works at all? Runs plenty cool enough.

×
×
  • Create New...