Quote from: thepenguin77 on October 28, 2011, 11:20:41 pm

2. Scrolling is a bit harder, any way you do it it's going to be messy. I have two approaches, the oversized buffer method, and the clipping method.

• Oversized buffer: For this, you'll want to allocate a big buffer, 150x150 pixels should be fine. Then, you'll have to make your own drawing methods to draw to this buffer. You really only have to copy over a line drawer and a vPutS, which isn't really that tough. After that, you simply draw you whole molecule to the buffer and only display the 96x64 region that is currently showing.
• Clipping method: This method might be harder, but it uses fewer resources. You will probably be able to use the system vPutS for this but you'll need a special line routine that automatically clips itself to the edges of the screen. (badja made one). From here, you also need to define how far the screen has scrolled from the top left corner of the true screen. The final step is just to take the coordinates of something on the screen, subtract from it how much the screen has shifted, and draw the atom to the resulting position on the screen. You'll just have to watch out to make sure that you don't accidentally try to vPutS something off the screen.
  

I would highly recommend not going with the virtual buffer method. As you mentioned, it's messy. It's also rather inefficient for long carbon/Silicon chains where you have large 2d plots, but relatively few molecules. I'd instead recommend a more "vector"-ish approach where the coordinates of the nuclear centers are represented in a virtual 3d space as a table of coordinates and bond relations. When you need to display them, you define a 2d buffer that will be directly translated to the screen and just project the points from that 3d space into the buffer along with the bonds. A bit more complex, perhaps, but it allows "infinite resolution" of arbitrarily large molecules (within reason of course) and uses a less memory for molecules with low nuclear density since all you're storing is an extra coordinate over the 2d buffer method.

As for generating the structures themselves from the formulas, I'll be blunt. It's basically impossible to do at any significant level of accuracy, since the structure of a molecule depends on a lot more than just an enumeration of the atoms in it. For example, it often depends on the prior history of its constituent atoms. A good demonstration of this is Barrelene, a molecule with the formula C8H8. This molecular formula is also shared by Cubane and Styrene, among a few others. These isomers are all [somewhat] stable in their radically different configurations and determining which one the user means is nigh impossible. A structural formula like SMILES is much less ambiguous, pretty widely available for most molecules, and essentially eliminates the near impossible problem of predicting molecular structure.

Quote from: Xeda112358 on October 11, 2011, 08:24:12 pm

So if you want to delay for approximately 'a' seconds you can try this:

Code: [Select]

     ld b,107
     halt
     djnz $-1
     dec a
     jr nz,$-6
     ret
Does this help?

Remember to have interrupts enabled. 

1. I know my house might get bombed for this, but honestly, the only way I can see to do this would be to check out how Axe does it. Axe draws perfect circles very quickly and if I needed a circle routine, I would just copy axe's.

2. This one has actually been done for you, bcall(_DrawRectBorderClear) draws a rectangle with a white inner section. (Page 142 if your browser doesn't redirect you)

3. If you mean just draw text, then bcall(_vPutS) is your routine. But, if you mean draw text within a certain boundary area, bcall(_SFont_Len) will tell you how long an individual letter is. From there, you can draw the letters 1 by 1 with bcall(_vPutMap) and start a new line whenever you run out of space. (bcall(_SFont_Len) is on page 47 of that pdf I linked above)

4. There are so many sprite rendering routines, there's no need to make a new one. Here is a page for 8-bit wide sprites and here is a page for 16-bit wide sprites. However, if you want just a single routine to do all of your sprites no matter how big they are, this is your routine. Of course, picking one of the smaller ones would be faster than this though.

As for the delays, your best bet is to make a single delay routine and call it.  In all honesty this routine right here is probably all you need:

Code: [Select]

Delay:
dec hl
ld a, h
or l
jr nz, delay
ret