Grebnedlog

Ah, sorry. I actually did have 3.7.2 installed, but the for some reason the Visual bB devkit program I was using was mapped to an archived version when I took the screenshot. In any case, the ARM error still seems to occur when I run it with Stella 3.7.2 (see attached JPEG). Also, sorry to be a pest, but what would the syntax be to turn off the trap? Thanks.

I agree, it would be nice to think of other applications for this. My application was very specific and limited (loading hi-res playfields for DPC+ games without using the graphics bank). I guess that bit arrays might also work pretty well for storing a bunch of scrollable playfield data too, but not using the specific pf-drawing routine I wrote. That works fine for drawing a static playfield before UI starts, but it's too cycle intensive to nest in any sort of looping gameplay. In general, I guess the application would be that storage of any binary data that requires >256 values. But I'm thinking binary values would probably be most useful for storing playfield and sprite pixel states -- and, as far as I know, there is no "playerpixel" command for writing to player sprites, so storage of playfield data is probably the most applicable thing for most kinds of Atari games. As for including this on Random Terrain's bB page, what exactly is it that needs to be up there? Is it just a brief explanation of how to structure a bit array and read values from it? If that's the case, are we sure that the method we've come up with on this thread is the simplest/most-efficient one? It works well, but I'm just wondering about other ways to do it (and other ways to demonstrate it).

Does anyone here know enough about how ARM emulation works in Stella to explain what this recurring crash message means (attached JPEG), and how one might go about troubleshooting it in a program? Are there instructions or methods that other programmers have found to generally cause these kinds of errors?

Yes that is better, thanks.

Yeah, that's what I meant. You could do it with cases or conditionals. It was sort of a broad question (whether this could be adapted for random mazes). The short answer is "of course it can", but it can be done in almost too many ways to describe. In addition to randomizing the pointer, you could also assign another byte of RAM that points to different IF statements. For instance: dim current_row = a dim current_col = b dim current_byte = c dim current_bit = d dim lo_pointer = e dim print_row = f dim chunk_start = g dim maze_ref = h ... WritePFChunk for current_row = 0 to 7 lo_pointer = current_row * 4 for current_col = 0 to 31 current_byte = current_col / 8 + lo_pointer current_bit = current_col & 7 print_row = chunk_start + current_row on maze_ref goto MazeData1 MazeData2 MazeData3 MazeData4 MazeData1 if mazes1[current_byte] & setbits[current_bit] then pfpixel current_col print_row goto Continue WritePFChunk MazeData2 if mazes2[current_byte] & setbits[current_bit] then pfpixel current_col print_row on goto Continue WritePFChunk MazeData3 if mazes3[current_byte] & setbits[current_bit] then pfpixel current_col print_row on goto Continue WritePFChunk MazeData4 if mazes3[current_byte] & setbits[current_bit] then pfpixel current_col print_row on Continue WritePFChunk next next How he arrives at the value of "maze_ref" is completely up to the programmer, of course. It could perhaps increment with the levels or stages that a player advances through, or could itself be randomly assigned. EDIT: Boy, this forum software really messes up the spacing inside CODE tags.

I see no reason why it couldn't be used with any kernel version. The routine isn't doing anything that's specific to the DPC+ kernel. The only reason I picked that one is because that's the kernel I'm working with at the moment, and because I think it's greatest usefulness would be with drawing hi-res playfields that eat up a lot of ROM space. Again, I don't see why not. For instance, you could just define offsets that point to the various regions of the maze, then randomize which segment of the array it reads during the pfpixel routine. For instance, when using this method each row of playfield pixels is defined by 4 bytes, meaning that each data statement can contain 64 playfield rows (or one 64 row x 32 column playfield). So, if you were using the optional superchip 23 visible rows (23 x 32) display, you could maybe break each maze down into 4 segments of 16 rows (or 8 segments of 8 rows, etc), then do a rand command in conjunction with "current_row" to pick the starting point of the segment you want to draw. And that's just one of many ways to do it. I see no reason to even be limited to a single data statement to draw a semi-random "maze-style" playfield. You could always look up data segments in multiple arrays for your maze pieces, in whatever way you see fit. All this routine does is draw whatever binary image is fed into it.

Is what a typo? Not sure I understand your question, but I'm using bB version 1.1d.

Yep. I posted the BAS above.

I'm sure you would have spotted it eventually.

@bogax Okay, I see the problem. The elements in your setbits array were just in reverse order. Changed it to this and it works fine now: data setbits %10000000, %01000000, %00100000, %00010000, %00001000, %00000100, %00000010, %00000001 end Thanks again! I think this could be very useful for hi-def playfield drawing. EDIT: Attached a BAS file combining all edits and corrections. draw_pf_from_binary_array.bas

Oh, okay. Got it now. Ha! Based on that other thread, I'm fairly sure you know what you're doing. Now I just want to be sure that I know what you're doing. Thanks! The resulting binary looks close to correct. However, instead of saying "HELLO", my screen looks like this: I believe that's Klingon for "Destroy all humans" Seriously, though, I guess it looks like it's reading some of the data in backwards, and starting to write it in the middle of the screen. Any ideas? EDIT: Oh, I also forgot to mention that bB cannot see data in different banks from the one that is reading them, so I cut and pasted the arrays back into bank 2 with the WritePFChunk routine (though, I suppose, you could alternately stick the routine in bank 6, and then bankswitch to it from the main loop.)

Well, I guess the idea is a based on a tradeoff. In this case, the tradeoff is between hi-res playfield definitions and hi-res sprite definitions. Both share the same bank in the DPC+ framework, so if you want more of one, you'll necessarily have less of the other. If I wanted to have 88-row multicolored playfields (which I do) and had to rely solely on using the static playfield definitions, I wouldn't be able to include very many of them, and won't be able to include lots of sprite data either. Live playfield drawing seems far more useful in general for hi-res screens, but particularly if you want to have lots of varying kinds of sprites. From what I can see, the loop statement I used isn't really using that many more cycles than a string of successive static pfpixel commands would (and the screen would roll for either version, if you don't take precautions). Also, your version uses 1650 bytes of ROM, and to draw only 11 rows in one static position. My version draws 8 rows wherever I want them, and only uses 373 bytes (256 of which is the data array itself, and the other 117 of which can be reused to draw multiple screens) and it will use far less still if we can get binary arrays working. Actually, that would be really exciting... if that was the case, a single data statement could draw a full, fairly high resolution screen without sacrificing any space for sprite data.

No offense intended, but I'm not sure why would that be better than my nested loop statement. I mean, both our versions work, but your version seems like it would be a nightmare for drawing lots of pictures with. Design workflow for my version would just involve drawing a playfield in the ordinary way (either by using tools or typing it out ASCII style), using find-replace to comma separate, copying it into a data array (in the bank of my choosing), and having the program run the routine whenever I need to draw or redraw a section of the playfield. Also, my version allows the programmer to vary the position (vertical only, right now, but probably easily adaptable for horizontal) of the playfield graphic being drawn. For instance, with my V2 version, you can change the message from "HELLO WORLD" to "WORLD HELLO" simply by changing "chunk_start = 20" to "chunk_start=70", whereas your static version would require recoding all the pfpixel statements to achieve the same effect (essentially doubling the ROM space used, too). Actually, for the particular project I had in mind this wouldn't be a problem, since the drawing routine doesn't happen during gameplay, but rather before a new game level starts (i.e. setting up the game map, obstacles, etc). I essentially shut off the display while this is going on by reducing the screen resolution to 1 until the process is finishes, meaning the screen won't appear to roll even if the improper number of scanlines are drawn (which, they most definitely will be). I've tested this on real hardware and it works pretty much as expected. The screen goes black for a second while the drawing is done, and then I increase the screen res just before the level starts. Well, I guess we'll have to agree to disagree on that one. I personally am finding the temp vars indispensable for certain in-game routines (particularly for things like soft collisions, where a temp can act as a second "edge" for a sprite coordinate during an overlap test). It's true they aren't useful as general purpose variables (seing as they are temporary), but not using them at all seems a little extreme.

Okay, I think I see what you mean. If so, then yes you are right that it is the wrong number of iterations. I changed it to "for current_row 1 to 8." Thanks! Is there any chance you can help with converting this to a binary bitmap routine?

When lo_pointer is zero, the routine is searching the array values representing the first row in the "playfield chunk" (i.e. the segment of the playfield being drawn). The lo_pointer advances by 32 on each iteration to draw the next playfield row, starting with playfield position 0 and advancing to position 31. The routine checks the value, then draws a pixel if it reads a "1". As RevEng and theloon pointed out above, this routine would obviously be a lot better (and more useful) if the array data could be read as a binary array, since only on/off states are needed. I'm fighting my way through the binary array examples you provided on that other thread, but I'm not sure how to adapt it to this purpose. Any help would be much appreciated.