Ornelaz: And then do a draw call

Ornelaz: You dont want to spend texture memory on a 4096×4096 tile map

Vories: Is there an algo to find out what is visibe though?

Ornelaz: Uh, it’s just checking if it’s in the view

Ornelaz: Presumably you have the tiles in an array

Maret: Tcsc, my current implementation is already what you described for the drawImage and tilemap, except my tilemap is an array of ImageData instead of a big context

Ornelaz: Putimagedata is pretty slow, actually

Ornelaz: Slower by a lot than drawimage

Ornelaz: Since it needs to do a texture upload too

Ornelaz: Vories: and theres some mapping between game units and tiles

Ornelaz: Lets say like in jkoudys’s case 8 game units = 1 tile

Vories: That’s so interesting. you hang around on #webgl too?

Ornelaz: Nobody talks on it but yeah

Vories: So we need to spam here :

Ornelaz: You’d loop over the stuff between Math.floorminCameraX/tileWidth . Math.ceilmaxCameraX/tileWidth and Math.floorminCameraY/tileHeight . Math.ceilmaxCameraY/tileHeight

Ornelaz: And all those tiles are visible

Mceachran: Slightly different computation if you’re using an isometric tilemap, but same idea

Mabon: There is some requirement around 8×16 tiles e.g. Mario himself is 16 pixels tall, so I can see how that approach could be easily adapted for the 2-high tiles too

Ornelaz: You usually want a different approach for entites

Delawder: Jkoudys: you’d usually not place sprites in the grid

Vories: Years ago i managed to build a pure grid renderer and was very proud

Vories: I used only what i learned in school about vectors

Mcclam: Jkoudys: so you have the tilemap which you render that way, and then you have a grid or quadtree or whatever that holds the entities in your game, and you can compute collisions between them, and move them by subpixels, rather than one whole tile at a time.

Vories: It was slow but. it worked. the key enlightment moment was to realize depth is just scale down to the center :

Ornelaz: In all honesty you could batch entities pretty aggressively, but i wouldn’t worry about it a ton unless you have hundreds on the screen and say you’re ok with 1 draw call per entity

Siren: Dolby, I’m not writing a game

Ornelaz: Vories: oh, a 3d renderer?

Bonin: Dolby, I’ve already written an emulator

Ornelaz: Thats actually a really good exercise

Alatosse: Which works reasonably well, but my renderer ****s

Ornelaz: Did you have texturing?

Dietsch: Could someone recommend a parallax library

Shirai: Haven’t found one yet that’s still maintained

Vories: And i have no idea how.

Vories: Would need to read things up.

Sheinbein: Dolby, my design goal is to write an extremely inaccurate emulator. Most other devs seem oddly obsessed with ‘accuracy’ in the emulator, so it runs as closely to the original hardware

Vories: Good to know i can bother you from time to time 3;:-

Ornelaz: Yeah i’m on here usually

Krupke: Isn’t that the point of an emulator?

Zurawik: Dolby, hence my reference apps tend to render the screen by running scanlines and doing it pixel-by-pixel. My goal is to make something that plays games really well

Vories: If you have a hint for texturing . a link or sth. would be nice.

Vories: Else i can use search engine usually.

Leuze: Jkoudys: You *have* to do scanlines pixel by pixel if you want to play games really well.

Sverchek: Not accurate to the hardware, but accurate to the intent of the game developer. e.g. if tiles normally disappear if there’s more than 8 of them on a line, that’s a limit of the hardware. Some games might look good like that, but others won’t.