Jump to content

Kurt_Woloch

Members
  • Content Count

    1,780
  • Joined

  • Last visited

Blog Comments posted by Kurt_Woloch


  1. I think the same way too. That's why I didn't do much about homebrewing myself (heck, I already work as a programmer as my main job!). But every now and then the bug bites me again... that's why yesterday I did a hack of Atari 2600 Pole Position and put it up in the "Hacks" forum.

     

    I wouldn't say you're a nuisance... some people are better at programming and some are worse, just like some are better and some are worse musicians. But those who do it in their free time aren't expected to be a master in the craft. That's why you find many amateur bands around playing music which they wouldn't be able to sell, but they still enjoy doing it. So... in the end it all depends on if you enjoy doing it if you're not in for the money. As Wham said... Do you enjoy what you do? If not, just stop, don't sit there and rot!


  2. This reminds me of what I read yesterday about old "Albums". Before there were LP's, an album was basically a set of 78 RPM records holding one song on each side. For example, the broadway cast album for "Oklahoma" consisted of 6 78 RPM discs with a total running time of about 37 minutes. You certainly weren't able to fit such a long song on an album like that back then.


  3. Actually, the maps are pretty compact as they are... you actually only write out 18 bytes per level. What's actually bloating up the size is that you write everything using distinct commands ratger than reading the data from a table.

     

    You could read all your level data from a table, similar as you do it now for your shape data. Actually, part of your shape reading routine could be re-used for doing this. For even more effiency, since you need multiple sets of level data, you could read the start of each level from a table itself.

     

    Your new_level routine then would look something like this:

     

     

    new_level:

     

    ;call gfxoff

     

    mov r1,#level_number ; only R0 and R1 can be used as pointers to intram

    inc @r1

     

    mov a,@r1 ;a now contains level number

     

    add a, #levelstarts & 0ffh ;add start of level starts table

    call read_levelstart

    mov r1, a ;store in pointer to read

     

    mov r0,#004h ; pointer to sprite 1 Y pos in VDC (X pos and color follow afterwards)

    mov r7, #3 ;3 bytes (Y and X pos and sprite color) to copy

    call copyspriteloop

     

    mov r0, #0c1h ;pointer to horizontal grid lines in VDC

    mov r7, #7 ;7 bytes to copy

    call copyspriteloop

     

    mov r0, #0e1h ;pointer to vertical grid lines in VDC

    call setshape ;sets r7 to copy 8 bytes

     

    jmp reset_sub

     

    Then, you need the routine to read the level data starts:

     

     

    read_levelstart:

    movp a, @a ;get byte

    ret

     

    This must be on the same page with the level start data, which looks like this:

     

     

    levelstarts:

    db #level_1_data & 0ffh ;start of level 1 data

    db #level_2_data & 0ffh ;start of level 2 data

    (and so on for each level you include)

     

    Then, on the same page with your sprite data, you have your level data, which now looks as follows:

     

     

    level_1_data:

    db #020h ; sprite 1 Y pos

    db #03bh ; sprite 1 X pos

    db #col_spr_yellow ; sprite color

    db #081h, #081h, #0cbh, #0efh, #0e7h, #0cbh, #089h ;horizontal grid data

    db #07fh, #07eh, #03fh, #010h, #008h, #01ch, #032h, #07fh ;vertical grid data

     

    level_2_data:

    (data bytes for level 2 structured as above)

     

    and so on...

     

    Only if with all data bytes you exceed one page (which will probably happen if you need more than 13 levels), you need multiple read routines like the setshape / copyspriteloop routine, which then has to be duplicated in every page you need for level data. But still, this way you can use the majority of the data pages for actual data without the need for a ton of MOV lines.


  4. I've also had problems watching Flash videos one or two months ago... the whole CPU would intermittently stop, then start again for a split second, then stop again. Sometimes it would never start again so I'd have to switch the PC off. But it fixed itself by now somehow... I guess they introduced a bug while updating the Flash player which I have on auto-update, happening quite often. Maybe you have a similar problem which will fix itself in a subsequent Flash player update...


  5. Maybe it's the trashcan that turns full. You see, if you delete a file, it goes into the trashcan first, where you can restore it from. But while it's there it still occupies memory. Only when you empty the trashcan, the memory gets freed.

     

    Then there's some sort of automatic cleanup which engages if memory becomes low. This happened to me multiple times on my old PC, and it freed up some serious memory.

     

    Then there's the possibility of backing up data, and of expanding. In the 80's, usually home computers didn't have a hard drive at all, so everything had to be kept on tapes or disks which were external to the computer. And you could buy as many as you needed as they filled up. Then the first small harddisks came, but they were expensive, so I regarded them as a means of speeding up operation by keeping the OS and your most-needed programs and projects on. On my first PC, the harddisk only had 20 MB of storage, so I only had the OS and the core software on it, but all projects were still stored on floppy disks. With bigger harddisks, I moved some of the projects I was currently working on and which needed to be on a harddisk (such as Access databases) onto the harddisk as well, but all finished projects were still compressed and stored on floppies.

     

    Then my previous PC initially had a 40 GB harddisk, but I managed to fill it up in about 6 months, at which point I started backing up the data on CD's and subsequently deleting everything finished from the harddisk, freeing up some space. Then some more months later I added another internal 120 GB harddisk to the system. The CD writer was later upgraded to a DVD drive, allowing me to store even bigger amounts of data on one disk. Then finally, after 6 years, I did buy the PC I'm using now... not because of storage shortage, but because the old PC was too slow for some modern software, and I needed to upgrade the OS because more and more programs didn't run on Windows ME. My current PC has two 360 GB drives built in, but I continued to backup my data on DVD's for security reasons, and eventually I switched to a 1 TB external harddrive for backup. Still I haven't deleted much from the internal harddrives, but I'm now at the level where my second internal harddrive (which is mainly used for storage, not for current projects) only has about 4 GB left, so I will have to delete some stuff from it which is backed up on the external harddrive anyway. But that doesn't hurt, and I'll definitely not buy a new PC because of that.

     

    If your PC has other problems such as some programs not executing properly anymore, you may consider running a utility such as HijackThis or, in extreme cases, re-installing your PC. I had to do this about every other year because the system somehow became corrupted. This involves first backing up your data (if you don't know where to, I'd recommend buying an external harddrive for this purpose) and then re-installing the OS (probably Windows) and all the programs which you still need currently.

     

    I like to think of the PC as a set of storage which is organized in different layers, where the smallest inner layer is used most frequently, but also the easiest to access and the outer layers get subsequently bigger and harder to access, but are also used less frequently. In real life the most inner layer would be your hands, but since you can only hold so many things with your hands, you'll need to put the things you don't currently need somewhere else, like on the table before you. But the table probably also won't be able to hold everything you need regularly, so you'll put some things you don't need that often away into some cupboard or other furniture, or even farther away in a storage room.

     

    It's the same with a PC for me. It has the CPU where all the data flows through, then the RAM, then the internal harddisk. When that fills up, less frequently used data gets stored onto the external harddisk or other media.

     

    A good analogy to this would actually be the Odyssey^2 system, where even the CPU contains multiple of such layers... there's the accumulator a where nearly everything flows through, then the index registers r0 and r1 which get used for nearly every memory access, then the registers r2 through r7 which probably hold some temporary variables with, let's say, a subroutine scope. Then there's internal memory and external memory. Each of those layers, in sequence, is somewhat harder to access, but also somewhat bigger and typically gets used if the inner layers fill up with data. The Odyssey^3 has yet another layer in the video memory which is even bigger (at least 2K), but also the most difficult one to access.

     

    So... if your PC fills up, I guess it's time to put some data to an outer layer, even if it has yet to be created, or to delete some of the data you don't need anymore.


  6. OK... I, too, think it's a bit pessimistic to call it "the end of everything". At least in the thread about Jack and the beanstalk, I didn't have the impression that people aren't liking your game. I think they seemd to like it very much, at least most of the people on the thread said so. And even though it's unfinished, it already gets a lot of play as you can see in this thread: http://www.atariage.com/forums/index.php?s...=133276&hl=

     

    Ultimately, I think, it depends on if it's fun FOR YOU to go on with this project. I know I'm starting several projects only to drop them a short time after since they turn out not to be as much fun as I thought they'd be... or they turn out to be much more time consuming than I thought they'd be. An example for that would be this one: http://www.atariage.com/forums/index.php?s...=113751&hl= ... a project I started back in 1998, then dropped it, then continued to work on it a bit in 2007, then dropped it again. When I started on that project, I just thought it would be cool to do something like that again, but after a while I got tired of constantly debugging and testing code, so I started to do something else. But I never called the project "cancelled"... maybe it will be finished someday, but maybe it won't.

     

    Anyway, about that "crappy" quality let me just say I produced many of those "crappy" games back in 1983 on my TI-99 in XBASIC. However, there weren't intended to be released to the public, so many of them just sit there unfinished, which means you can play them for a while, but if you reach a certain level, the program stops with an error message because that level isn't programmed yet. Compared to that, "Jack and the beanstalk" looks "finished" in the respect that the loop is closed... there's no unexpected ending of the game (it ends either if you've finished it or lost all your lives), and as such it's finished in a way that I'd consider each of the last 10 versions you put out "releaseable", meaning they could be released that way if you decide not to go on with the project. Hey, there may be a few bugs in there, but there are also bugs in other commercially released Atari 2600 games.

     

    And about you planning to commit suicide... I also planned that about a year ago, but didn't do it in the end. I understand that you probably have got problems in your life which make you think you'd rather be dead. I also understand that many people rather don't want to go into this topic, but if you need someone to talk with about this, I'm here to help. You can write me a PM if you want, and then we can continue talk in MSN Messenger or in a different chat or something like that, or via PM's or mails.

     

    With greetings from Austria

    Kurt

×
×
  • Create New...