Welcome to omnimaga.

...and have some moar peanuts.

pretty much all code that's commented out were either failed tests or debug code. You can just ignore those parts.
The part after the first header sorts the points based on their Y-coordinate (from smallest to biggest)
The secound part sets up flags and variables, and it calculates some numbers. For example dx is the fixed-point number that needs to be added in every scanline to adjust the X and make the line meet at the next point.
The part after that calculates some values for the scanline (drawloop is the loop in wich scanlines are drawn, 1 cycle=1scanline). The first part does vertical clipping, then it checks the start and the end and when nessicary it switches them so the scanline can always be drawn from left to right. Then GetPixel is called and saved so it only has to be called once per scanline. The rest of that part is texture interpolation.

PlotLoop is the loop in which the pixels are plotted. 1 cycle = 1 pixel.
It basically just reads the pixel of the texture at coordinates calculated in the part before this one, and plots that pixel. Then it shifts the texture coordinates and adjusts the results of the getPixel to plot the next pixel.

After that, the values for the scanlines are calculated again to update the x coordinates and texture coordinates.
after the end of pizel plotting code comment, the variables are updated to draw the bottom half of the triangle. After repeating the loop, the triangle is complete and it returns.

The getPixel routine bihind that was just as documentation, so you could see which one I'm using and what exactely that it does. I doubt that that can be optimized.

If anything isn't still clear, feel free to ask.

you should try to use GM8.0. It hasn't got a watermark in the free version.

You should also try to make you keep walking in a direction when you hold down an arrow key.

progress went slowly because the OS ate my source files a few times, but here's a small update: the world generation now generates a hilly landscape instaed of the flat landscape with a few block at higher and lower coordinates, the bug that made trees sometimes spawn next to eachother and overlap has been solved, and large narrow veins of iron ore are generated. The long narrow shape isn't intended, the blocks are placed randomly, but somehow they often group together in veins. That's it. I hope you enjoy.

I wrote some communication routines to send bytes from an 84+ calculator to the arduino (not from arduino to calc).
Here is the example code:

z80:
.org $9D93
#define bcall(label) rst 28h \ .dw label

#include "ti83plus.inc"

.db t2ByteTok, tAsmCmp

  call USB_Init

  bcall(_GetKey)

  ;send 50
  ld b, 50
  call USB_SendByte

  ret

;------------------------------------------------
; calc-Arduino communication routines trough USB
;------------------------------------------------


USB_Init:
  ;initializes the USB connection

  ;turn the USB driver off so we can read and write manually
  bcall(810Eh) ;KillUSB

  ;put the D- line on low
  ld a, %00100000
  out ($4A), a

  ret


USB_SendByte:
  ;b = the byte to be send
  ld c, 0
  ;c = bitcounter

  call Wait

  ;set D- to high so the arduino knows we will send a byte
  ld a, %00011000
  out ($4A), a

  ;wait untill we can start sending the byte
  call Wait

SendLoop:
  ;put the bit we are going to send in carry
  rrc b

  jr c, sendOne

  ;send a 0
  ld a, %00100000
  out ($4A), a
  jr endBit

sendOne:
  ;send a 1
  ld a, %00011000
  out ($4A), a

endBit:
  ;increase the bit counter
  inc c

  ;stop sending if all 8 bits were sent
  ld a, c
  cp 8
  jr z, endSend

  call Wait
  jr sendLoop

endSend:
  ;set D- low so the arduino won't think we're trying to send an other byte
  ld a, %00100000
  out ($4A), a

  ret


;internally used routine(s)
;--------------------------

wait:
  ;waits untill you can send a bit

  ;if the clock is 0: wait untill it's 1
  in a, ($4D)
  bit 1, a
  jr z, Wait

waitLoop2:
  ;Wait untill the clock is 0, so we can begin writing
  in a, ($4D)
  bit 1, a
  jr nz, WaitLoop2

  ret

arduino

//Dp and Dm are the data kables of the USB
const int Dp = 5;
const int Dm = 6;
const int Delay = 1;

int RecievedByte = 0;
int Recieving = 0;
int RecievedBit = 0;
int Recieved = 0;
int ledOn = 0;

void setup(){
  pinMode(Dp, OUTPUT);
  pinMode(Dm, INPUT);
  pinMode(13, OUTPUT);
}


void loop(){
  digitalWrite(Dp, HIGH);
  //clock = 1 so we'll read a bit
  if(Recieving == 0){
    //if nothing is being sent, we have to check for a 1
    if(digitalRead(Dm) == HIGH){
      //1 was send, so we'll have to recieve a byte
      Recieving = 1;
      RecievedBit = 0;
      RecievedByte = 0;
    }
  } else {
    //save the received bit
    if(digitalRead(Dm) == HIGH){
      bitSet(RecievedByte, RecievedBit);
    } else{
      bitClear(RecievedByte, RecievedBit);
    }
    RecievedBit++;
    if(RecievedBit == 8){
      //if all 8 bits are sent, the byte is complete.
      Recieving = 0;
      Recieved = 1;
    }
  }
  delay(Delay);
  digitalWrite(Dp, LOW);
  if(Recieved){
    if(RecievedByte == 50){
      if(ledOn == 0){
        digitalWrite(13, HIGH);
        ledOn = 1;
      } else {
        digitalWrite(13, LOW);
        ledOn = 0;
      }
      RecievedByte = 0;
    }
    Recieved = 0;
  }
  delay(Delay);
}

HOW TO USE THE EXAMPLE PROGRAMS:
- BACKUP YOUR PROGRAMS AND OTHER IMPORTANT DATA ON YOUR CALC
- compile the z80 program (I used SPASM) and send it to your calc.
- send the programs to the arduino and the calc.
- if the arduino hasn't got an on-board LED, connect one (and a resistor!) to pin 13.
- cut a USB mini male end of a USB cable (make sure the wire attached to it is long enough, works with both A-type and B-type (both have been tested)).
- connect the white wire of the USB to pin 6, the green wire to pin 5 and the black wire to the GND.
- make sure the arduino is powered and insert the USB cable into the calc's USB port.
- run the assembly program with Asm( on the calc

When you run the program, press a key. The led should now turn on. When you run it and press a key again, the led should turn off. If your calc freezes, make sure the arduino is powered, the black wire is connected to the GND, runs the correct software and is connected to your calc.

What this does is: when you press a key on the calc, it sends a byte with a value of 50 to the arduino. The arduino notices a byte is send and checks if it's 50. If it's 50, pin 13 will toggle.

It may be very unoptimized (especially the arduino part, I learned the language two days ago), but it works. I hope this code can be usefull to anyone.

Also: thank you, Thepenguin77. Without your help, I wouldn't be able to control the USB port.

That's because when you reach the edges of the screen, the blocks in the edit buffer (the blocks that you see) are copied to the world and the blocks which are on an other location are loaded. this makes the part of the world that you can see shift by 8 pixels, and to make sure the player won't be stuck in blocks, the player moves 8 blocks as well. This causes the bad scrolling. I will probably once implement smooth scrolling, but I don't really know how to do that yet. I'm already glad the tilemap fully works and has collision checking and scrolling.

Since you all wanted it:


I hope you like it. It was hard to get it to work.

Screen ?

Sorry, I didn't have enough time yesterday to make a screenshot.

Here is one, showing the world generation (which is now also a lot faster).

[12:35:53] <+Runer112> I'm about to make one of my hackiest optimizations ever
[12:35:59] <+aeTIos> Oh
[12:36:04] <+Runer112> a good favorite
[12:36:08] <+Runer112> executing data as code
[12:36:12] <+aeTIos> let's celebrate it before TI ruins it
[12:36:13] <+OmnomIRC> (O)<hellninjas> :O
[12:36:24] <+OmnomIRC> (O)<hellninjas> RUNER NO!!
[12:36:31] <+OmnomIRC> (O)<hellninjas> YOU'LL BREAK TEH WORLDZ
[12:36:41] <+aeTIos> heh
[12:37:16] <+OmnomIRC> (O)<leafy> lolwat
[12:37:53] <+OmnomIRC> (O)<hellninjas> idk
[12:38:00] <+Runer112> wait shit
[12:38:04] <+OmnomIRC> (O)<hellninjas> RACIST
[12:38:12] <+Runer112> balls messed that up
[12:38:24] <+OmnomIRC> (O)<hellninjas> your balls messed up your program?
[12:38:26] <+OmnomIRC> (O)* hellninjas runs
[12:38:53] <+OmnomIRC> (O)* ben_g was thinking abouth that too
[12:39:00] <+OmnomIRC> (O)<hellninjas> lol
[12:39:02] * +New post by DJ_O in How we can improve Omnimaga? http://omniurl.tk/10502/239609
[12:39:11] <+Runer112> oh crap
[12:39:13] <+Runer112> that was even worse
[12:39:22] <+OmnomIRC> (O)<hellninjas> DJ_O
[12:40:11] <+Runer112> .z80 a9
[12:40:23] <+Runer112> man this is getting crazily hack
[12:40:24] <+Runer112> y
[12:40:25] <+OmnomIRC> (O)<DJ_O> nom
[12:40:42] <+OmnomIRC> (O)<leafy> his massive testicles clogged up the z80