Join us on Discord!
You can help CodeWalrus stay online by donating here.
Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Adriweb

#406
The v12 version from pad and Lionel Debroux is available here : https://tiplanet.org/pad_ti68k_emu/v12.html
Some time ago, I forked the page to have some better design : https://tiplanet.org/emu68k_fork/v12.html

But anyway, I'll let Lionel reply here directly, if needed :)
#407
The SmartView CE is an emulator (of the z80 and ez80)
(made in JavaScript, which runs rather slowly within their java software, but too fast in the browser...)
#408
well, sure but this has nothing to do with the webview inside the Java app I'm talking about :P
#409
About the emu speed...
It's in fact the SmartView java webview that slows things down greatly.

When trying out TI's emu in browsers with a simple for loop to 5E4, here's what we have :
Firefox : ≈ 10.5 s
Chrome : ≈ 10.7 s

For comparison, an actual 84+CE : ≈ 46 s
And then, the SmartView is even slower than the calc.... freakin' Java webview.... TI should have embedded v8 or something.

Details and video here : https://tiplanet.org/forum/viewtopic.php?p=182187#p182187
#410
The intended target market of the SmartView being teachers for classroom usage, it's kind of obvious TI didn't spend time on emulating things they would not need, like other LCD modes etc. ;)
Also the CE is already available in France (like the 82A apparently)
#411
In fact, so far, the TI-Planet/Jarrety offer is to get the USB wall charger for free, as the public price without the charger is 88.88 eur too (though Jarrety will change it to reflect a competitor (like TSP) selling it at a lower price).

Being in Canada I see the lack of graphing calc selling disturbing...
#412
Having TI use LuaJIT would be a great step forward already.
#413
Calc Projects, Programming & Tutorials / Re: Dino
May 09, 2015, 04:05:33 PM
Cumulating demos of the TI-Nspire Computer Software (student and teacher editions), you get 4 months of trial :) I'd recommend using 3.6 or later (though 3.9 got some nice lua additions)
#414
Well, I don't have time to go into specifics to actually give you some code, but do NOT use pcall for things like this. Really.
I mean, it's much worse than a bunch of ifs.

And well, what you need to do is just bound checking, AFAICS. It's clearly an easily solved problem when you think about it for a bit.

What I'd recommend doing is to store in some temporary variable the next position of what the player *would* be. Then, if it's an allowed value, use is as an index for getting the table element. So you won't get errors due to nil values.
So, instead of directly having unchecked read/writes of/to "board[player[1] - i][player[2] + i]", look at what player[1]-i is, same for +i.

Also, you should hugely refactor the on.charIn to do the least amount of code duplication possible. It should be doable at great length, considering the code look similar in many situations.

Let me know how that goes, and I'll come back later
#415
well, the on.paint modification is basically just an if (firstTime) then ...loops...  else ...ligher paints... end.
So it's definitely not that ugly.
And anyway, in the end, it's the performance that counts, for the user :)

Edit: see my general notes that I edited after, in my post above.
#416
Here's a code where the timer only fires when necessary (thus the invalidating will only happen when necessary too, and that's a huge cpu gain):
Tell me if that's better (without the clipRect already), on the device (a clipping rectangle is just to say that things not in this rectangle will not be painted, but for simple things like that maybe it's the same as the partial invalidate, maybe it's better, I actually haven't tested).

-- make a global distance value, for some reason
distance = 0

-- colors {{color, style}, {color, style}}
colors = {
  {"0xFFBF00", 'r'},
  {"0xB31B1B", 'r'},
  {"0x006B3C", 'r'},
  {"0x1560BD", 'r'},
  {"0x872657", 'r'},
  {"0xFFBF00", 'b'},
  {"0xB31B1B", 'b'},
  {"0x006B3C", 'b'},
  {"0x1560BD", 'b'},
}

-- is the player moving
isMoving = false

function on.resize(w,h)
    -- font width & heights
    -- hardcoded because my other method only worked on the emulator for some reason
    strWidth, strHeight = 7,13
   
    -- window width & height
    winWidth, winHeight = w, h
   
    -- window width & height, character wise
    wincharWidth = math.floor(winWidth / strWidth)
    wincharHeight = math.floor(winHeight / strHeight)
   
    reset()
end

function reset()
    -- player location {x, y}
    player = {math.random(1, wincharWidth), math.random(1, wincharHeight)}
   
    -- generate board {{x, y}, {a, b}}
    board = {}
    for x = 1, wincharWidth do
      board[x] = {}
      for y = 1, wincharHeight do
        board[x][y] = math.random(1, 9)
      end
    end
    board[player[1]][player[2]] = nil
    platform.window:invalidate()
end
on.escapeKey = reset

-- game loop
function on.timer()
  -- move player
  if isMoving then
    -- operate in the appropriate direction
    if direction == 1 then
      -- clear next spot
      board[player[1] - 1][player[2] + 1] = nil
     
      -- change player position
      player[1] = player[1] - 1
      player[2] = player[2] + 1
    elseif direction == 2 then
      -- clear next spot
      board[player[1]][player[2] + 1] = nil
     
      -- change player position
      player[2] = player[2] + 1
    elseif direction == 3 then
      -- clear next spot
      board[player[1] + 1][player[2] + 1] = nil
     
      -- change player position
      player[1] = player[1] + 1
      player[2] = player[2] + 1
    elseif direction == 6 then
      -- clear next spot
      board[player[1] + 1][player[2]] = nil
     
      -- change player position
      player[1] = player[1] + 1
    elseif direction == 9 then
      -- clear next spot
      board[player[1] + 1][player[2] - 1] = nil
     
      -- change player position
      player[1] = player[1] + 1
      player[2] = player[2] - 1
    elseif direction == 8 then
      -- clear next spot
      board[player[1]][player[2] - 1] = nil
     
      -- change player position
      player[2] = player[2] - 1
    elseif direction == 7 then
      -- clear next spot
      board[player[1] - 1][player[2] - 1] = nil
     
      -- change player position
      player[1] = player[1] - 1
      player[2] = player[2] - 1
    elseif direction == 4 then
      -- clear next spot
      board[player[1] - 1][player[2]] = nil
     
      -- change player position
      player[1] = player[1] - 1
    end
    -- stop moving if the player reaches its destination
    if player[1] == destination[1] and player[2] == destination[2] then
      isMoving = false
      timer.stop()
    end
  end
  platform.window:invalidate(player[1] * strWidth - strWidth * 3, player[2] * strHeight - strHeight * 3, strWidth * 5, strHeight * 5)
end

-- controls
function on.charIn(char)
  -- make sure player isn't already moving
  if not isMoving then
    -- move player
    if char == '1' then
      direction = 1
      distance = board[player[1] - 1][player[2] + 1]
      destination = {player[1] - distance, player[2] + distance}
      isMoving = true
    elseif char == '2' then
      direction = 2
      distance = board[player[1]][player[2] + 1]
      destination = {player[1], player[2] + distance}
      isMoving = true
    elseif char == '3' then
      direction = 3
      distance = board[player[1] + 1][player[2] + 1]
      destination = {player[1] + distance, player[2] + distance}
      isMoving = true
    elseif char == '6' then
      direction = 6
      distance = board[player[1] + 1][player[2]]
      destination = {player[1] + distance, player[2]}
      isMoving = true
    elseif char == '9' then
      direction = 9
      distance = board[player[1] + 1][player[2] - 1]
      destination = {player[1] + distance, player[2] - distance}
      isMoving = true
    elseif char == '8' then
      direction = 8
      distance = board[player[1]][player[2] - 1]
      destination = {player[1], player[2] - distance}
      isMoving = true
    elseif char == '7' then
      direction = 7
      distance = board[player[1] - 1][player[2] - 1]
      destination = {player[1] - distance, player[2] - distance}
      isMoving = true
    elseif char == '4' then
      direction = 4
      distance = board[player[1] - 1][player[2]]
      destination = {player[1] - distance, player[2]}
      isMoving = true
    end
    timer.start(0.01)
  end
end


-- set background color to black
platform.window:setBackgroundColor(0x000000)

function on.paint(gc)
  -- render the board
  for x = 0, wincharWidth - 1 do
    for y = 0, wincharHeight - 1 do
      if board[x + 1][y + 1] then
        -- number appearance
        gc:setColorRGB(colors[board[x + 1][y + 1]][1])
        gc:setFont("sansserif", colors[board[x + 1][y + 1]][2], 10)
     
        -- draw number
        gc:drawString(board[x + 1][y + 1], x * strWidth, y * strHeight)
      end
    end
  end
 
  -- draw the player
  gc:setColorRGB(0xFFFFFF)
  gc:drawString('P', (player[1] * strWidth) - strWidth, (player[2] * strHeight) - strHeight)
end


Edit: updated the code to make it more modular.
Edit2: a bit better

General note: you could also optimize the on.paint to loop only through whatever needs to be painted (in which case, maybe not even loop at all anymore, only one time at the beginning to draw the whole board)
General note 2:regarding detecting the edges, instead of having a whole bunch of ifs (if that's what you were going to do), take a look at the __index key in the metatables (here, of the 'board' table) It's actually pretty much what I explain in my slides linked above (first one), page 13.
#417
Quote from: Strontium on May 04, 2015, 04:56:10 AMplatform.window:invalidate(player[1] * strWidth - strWidth * 3, player[2] * strHeight - strHeight * 3, strWidth * 5, strHeight * 5)
It didn't help much, not to mention how ugly it is.
Hmm, woot ?
When the area is properly setup, there should be no visual difference.
Also you can try mixing in gc:clipRect, see if that helps

Quote from: Strontium on May 04, 2015, 04:56:10 AMI also couldn't find anywhere I could implement the optimization tips in your presentation, unfortunately.
Yeah, that was in general, your code being sufficiently short and "easy", it wasn't really meant for this specific case.
#418
Ah, I see you use 3.9-style (apilevel 2.4) Nspire-Lua, by using setBackgroundColor and platform.window globally.
Note that this wasn't possible before (the "proper", universal way for w/h is to declare those width/height vars globally (you still can make them local but at the global scope, out of any function I mean), and initialize them with default values first if you want (generally 318, 212) and reassigning them in the on.resize event as it will fire quite early (after construction,activate,restore) with w,h as parameters.

Regarding speedup, your code is simple enough that it's a bit sad that it's slow on the device (well, I haven't tested but you say it is).
One thing I could see speeding it up greatly (and the only thing I can think of right now quickly reading your code *edit* well, nevermind, see posts below, don't always use the timer and paint !) would be to add partial invalidates instead of a full one, in the update loop, and thus only repaint the correct area in on.paint.
It should be fairly easy with this kind of grid-like based game.
Turns out that when benchmarking this technique (see here, but you only see the end result, and while it's not what's tested there, you may get this kind of speedup), the calc can even get slightly faster than TINCS (which doesn't care about partial invalidate...).

In general, I'd advise you to take a look at my presentations on Lua optimization and advanced scripting techniques *(shown at the T3 conferences in 2013 and 2014, and the first one being based on the one Levak and I did while working at TI India a few years ago (whoo, time flies)). Of course, take a look at Steve Arnold's tutorials if you haven't already, and Inspired-Lua in general (particularly the wiki, I guess) :)

* I really need to upload those on TI-Planet at some point, free.fr messed up...
#419
My 2 cents is that for 450 dollars, there's nothing that good for a laptop. (for a home-made destkop, though, that's another story)
You'll probably end up with something that may work at first but will rapidly degrade. I recommend spending a bit more at first to get a "real" thing, instead of having to spend smaller amounts multiple times at shorter intervals. In the long term you'll save money.

I've had a 1300euro PC laptop for school (public price was more like 1800 euro) and it turned to sh*t in like 2.5 years. So I can't imagine a 450 dollars thing doing any good...

(BTW, I know people like to trash talk Apple for their high prices, but at least I've never had durability issues with them :P PS: I pretty much don't use them for gaming but I occasionally do some CPU-intensive audio and video things, so I have one with a dedicated GPU, and I'm pretty happy with it. Integrated GPUs won't run big games, as said, anyway, and middle-range games will have to be put at a quite low level)
#420
Nope désolé, justement, pour ça que j'ai posté en Français pour ceux qui habitent en France :P

Cependant, si tu connais quelqu'un qui habite en France, ça fonctionne (c'est pour la livraison, en gros)
Powered by EzPortal